updated release_notes.stex to describe the recent fixes for bugs that

dated back to Version 8.4 or before and to combine the three performance
subsections directly related to the new compiler back-end, since the
changes all occurred between publicly available releases.

original commit: 65df1d1f7c37f5b5a93cd7e5b475dda9dbafe03c

release_notes/release_notes.stex

@@ -771,7 +771,7 @@ executed.
 
 There is no mechanism for the programmer to view block counts, but
 both block counts and source counts can now be saved after a sample
-run of the generated code for use in guiding various optimations
+run of the generated code for use in guiding various optimizations
 during a subsequent compilation of the same code.
 
 The source counts can be used by ``profile-aware macros,'' i.e.,
@@ -1421,6 +1421,43 @@ in fasl files does not generally make sense.
 %-----------------------------------------------------------------------------
 \section{Bug Fixes}\label{section:bugfixes}
 
+\subsection{\protect\scheme{string->number} and reader numeric syntax issues (9.4)}
+
+\scheme{string->number} and the reader previously treated all complex
+numbers written in polar notation that Chez Scheme cannot represent
+exactly as inexact, even with an explicit \scheme{#e} prefix.
+For such numbers with the \scheme{#e} prefix, \scheme{string->number}
+now returns \scheme{#f} and the reader now raises an exception with
+condition type \scheme{&implementation-restriction}.
+Both still return an inexact representation for such numbers written without
+the \scheme{#e} prefix, even if R6RS requires an exact result, i.e.,
+even if they have no decimal point, exponent, or mantissa width.
+
+Ratios with an exponent, like \scheme{1/2e10}, are non-standard and
+now cause cause the procedure \scheme{string->number} imported from
+\scheme{(rnrs)} to return \scheme{#f}.
+When the reader encounters a ratio followed by an exponent while in R6RS
+mode (i.e., when reading a library or top-level program and not following
+an \scheme{#!chezscheme}, or when following an explicit \scheme{#!r6rs}),
+it raises an exception.
+
+Positive or negative zero followed by a large exponent now properly
+produces zero rather than an infinity, e.g., \scheme{0e3000} now produces
+\scheme{0} rather than \scheme{+inf.0}.
+
+A rounding bug converting some small ratios into floating point numbers,
+when those numbers fall into the range of denormalized floats, has
+been fixed.
+This bug also affected the reading of and conversion of strings into
+denormalized floating-point numbers.
+[Some of these bugs dated back to Version 3.0.]
+
+\subsection{\protect\scheme{date->time-utc} ignoring zone-offset field (9.4)}
+
+\scheme{date->time-utc} has been fixed to properly take into account the
+zone-offset field.
+[This bug dated back to Version 8.0.]
+
 \subsection{\protect\scheme{dynamic-wind} mistakenly enabling interrupts (9.3.3)}
 
 A bug causing \scheme{dynamic-wind} to unconditionally enable
@@ -1793,14 +1830,19 @@ unprofiled run time.
 (Unprofiled code is also slightly faster, but by less than 2\% in
 our tests.)
 
-\subsection{Improved compile times (8.9.5)}
+\subsection{New compiler back-end (8.9.1, 8.9.2, 8.9.5)}
 
-Due to a rework of the new compiler back-end, Version~8.9.5 compile
+Versions starting with 8.9.1 employ a new compiler back end that is
-times are up to 20\% less in our tests, relative to Version~8.9.3,
+structured as a series of nanopassees and replaces the old linear-time
-with a corresponding reduction in memory allocation.
+register allocator with a graph-coloring register allocator.
-Compile runs that spend a significant portion of the time in macro
+Compilation with the new back end is substantially slower (up to a factor
-expansion will not benefit by as much.
+of two) than with the old back end, while code generated with the new
-Compile times are now reliably within a factor of two of Version~8.4.1
+back end is faster (14--40\% depending on architecture and optimization
+level) in our tests.
+These improvements are independent of improvements
+resulting from cross-library constant folding and inlining
+(Section~\ref{subsection:clcfai}).
+The code generated for a specific program might be faster or slower.
 
 \subsection{Open-coding of \protect\scheme{make-guardian} (8.9.4)}
 
@@ -1841,32 +1883,4 @@ constructors created by a record definition in one library and exported
 by another are inlined in the importing library, just as if the record
 type were defined in the importing library.
 
-\subsection{Faster generated code (8.9.2)}
-
-The code generated by the new compiler back end
-(Section~\ref{subsection:ncbe}) is faster.
-In our tests comparing Versions~8.9.2 and~8.4.1 under Linux, Version~8.9.2
-is faster on x86\_64 by about 14\% at optimize-level 3 and about 21\%
-at lower optimization levels.
-For x86, it is about 20\% faster at optimize-level 3 and about 25\%
-faster at lower optimization levels.
-Results for other operating systems should be about the same.
-These improvements are independent of improvements resulting from
-cross-library constant folding and inlining
-(Section~\ref{subsection:clcfai}).
-
-\subsection{New compiler back-end (8.9.1)\label{subsection:ncbe}}
-
-Versions starting with 8.9.1 employ a new compiler back end.
-As of Version~8.9.1, compilation using the new back end is approximately
-2--3 times slower in our tests.
-The code generated by the new back end for the x86\_64 is typically
-about the same speed as code generated by the old back end, while the
-code generated by the new back end for the x86 is typically faster,
-by an average of around 13\% in our tests.
-The code generated for a specific program might be faster or slower
-on either processor.
-The speed and effectiveness of the compiler should improve in subsequent
-releases.
-
 \end{document}