Re: WWWdocs updates

[Gerald Pfeifer <gerald at pfeifer dot com>]

On Mon, 11 Dec 2006, Jan Hubicka wrote:
> this patch updates webpage to mention memory tester and some of 4.2/4.3 
> changes that probably worth to be mentioned to end user. OK?

Thanks for writing this up!

I have a few specific comments below; please consider these before 
committing the final version.  Where possible, please try to make
sure line-length does not become too long (similarly for GCC code 
patches).

> Index: benchmarks/index.html
> ===================================================================
> --- 37,44 ----
>   
>   <p>
>   Similar to Diego's setup, Andreas Jaeger is running SPEC 2000 tests on
> ! AMD Athlon systems.  For details check
> ! <a href="http://www.suse.de/~aj/SPEC/amd64/";>http://www.suse.de/~aj/SPEC/amd64/</a>.
>   Other AMD Athlon and PowerPC64 SPEC 2000 results are available at
>   <a href="http://www.suse.de/~gcctest/SPEC/";>http://www.suse.de/~gcctest/SPEC/</a>.
>   </p>

I believe this is a noop, just reformatting?  If this is the case, omit 
this part.

> + <p>
> + Memory tester (maintained by Jan Hubicka) is periodically checking GCC memory
> + usage.  The reports are sent to

"A memory tester"?

"sent to the"

> + <A HREF="http://gcc.gnu.org/ml/gcc-regression/";>gcc-regressions mainling lists</A>

"mailing list" and "a href" and "</a>" (that is, lower case).

> + when some noticeable change is detected.   Dumps from last run are available at
> + <A HREF="http://www.suse.de/~aj/amd64";>http://www.suse.de/~aj/amd64</A>

"from the latest run"

Again "<a href" and "</a>" (lowercase), and please append a slash to the
URL, or users (and my link checker) will phase an additional redirect.

> Index: gcc-4.2/changes.html
> ===================================================================
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.2/changes.html,v
> retrieving revision 1.16
> diff -c -p -r1.16 changes.html
> *** gcc-4.2/changes.html	17 Oct 2006 22:36:15 -0000	1.16
> --- gcc-4.2/changes.html	11 Dec 2006 12:24:38 -0000
> ***************
> *** 117,122 ****
> --- 117,130 ----
>   
>   <h2>New Targets and Target Specific Improvements</h2>
>   
> + <h3>x86</h3>
> +   <ul>
> +     <li><code>-mtune=generic</code> can now be used to generate code running well
> +     on common x86 chips (for GCC 4.2 it includes AMD Athlon, AMD Opteron, Intel
> +     Pentium-M, Intel Pentium 4 and Intel Core 2.

"...chips.  This includes..."

Add </li> at the end of this paragraph.

> +     <LI><code>-mtune=native</code> and <code>-march=native</code> will produce code
> +     optimized for host architecture detected using <code>cpuid</code> instruction.

"for the host architecture"

"as detected using the <code>cpuid</code> instruction."

<li> instead of <LI>, and </li> at the end of this paragraph.

> Index: gcc-4.3/changes.html
> ===================================================================
> +     <li>Inliner heuristic is now aware of stack frame consumption.  New parameters
> +     <code>--param large-stack-frame</code>
> +     and <code>--param large-stack-frame-growth</code>
> +     can now be used to limit stack frame size growth caused by inlining.</li>

"command line parameters" (instead of just "parameters")

> + 
> +     <li>During feedback directed optimizations, the expected size of block <code>memcpy</code>,
> +     <code>memset</code> and <code>bzero</code> string functions operate on is discovered and
> +     for cases of commonly used small block size, the specialized inline code is generated.</li>

"specialized inline code" (without "the")

Something does not seem to match in the description.  Did you mean to
refer to block functions?  None of these functions is a string function,
and you have the string "block" and later "string functions" in that
sentence.

> +     <li><code>__builtin_expect</code> no longer require it's argument to be compile time
> +     constant.</li>

"requires"
"its argument"
"to be a"

> +     <li>Code generation of block move (<code>memcpy</code>) and block set (<code>memset</code>)
> + 	was rewritten.  GCC can now pick proper algorithm (loop, unrolled loop,
> + 	instruction with <code>rep</code> prefix or library call) based on size

"optimal algorithm" instead of "proper algorithm"?
"a library call"
"the size"

The "rep" prefix we only have on x86, so perhaps mention this, as in 
"...instruction with <code>rep</code> prefix in case of x86/x86-64, 
or..."?

> + 	of block being copied and CPU being optimized for.  New option

"the block", "the CPU"

"A new option"

> + 	<code>-minline-stringops-dynamically</code> has been added.  With this
> + 	option string operations of unknown size are expanded in a way so small

"such that" (instead of "in a way")?

> + 	blocks are copied by in-line code, while for large block library call
> + 	is used.  This results in faster code than

"a library call"

> + 	<code>-minline-all-stringops</code> when library implementation is
> + 	capable of using cache hierarchy hints.  The heuristic choosing particular algorithm

"the library implementation"
"the particular algorithm"

> + 	can be overwritten via <code>-mstringop-strategy</code>
> + 	Newly also <code>memset</code> of other value
> + 	than 0 is inlined.</li>

Have you considered making the last sentence a paragraph <li>...</li> of
its own?

> +     <li>GCC no longer put <code>cld</code> instruction before string

"places the <code>cld...."

> +         operations.  Both i386 and x86-64 ABI documents mandate direction
> + 	flag to be clear at the entry of function.  It is now invalid to set the

"the direction flag"
"entry of a function"

> + 	flag in ASM statement and do not reset it afterward.</li>

"<code>asm</code> statements"

"without reseting it afterward"


Thanks again for writing all this up, Honza!  This patchset is fine
with the changes I outlined above.

I recommend committing the varoius patches separately, but this is
just a most minor detail.

Gerald