This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [wwwdocs] Update changes-3.4.html
- From: Gerald Pfeifer <gp at suse dot de>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 31 Dec 2003 12:51:29 +0100 (CET)
- Subject: Re: [wwwdocs] Update changes-3.4.html
- References: <20031231102420.GC11524@kam.mff.cuni.cz>
Hi Jan,
thanks for this update! This is very important stuff to document, and
the summary is really excellent.
> Index: htdocs/gcc-3.4/changes.html
> ===================================================================
Several lines seem a bit too long, would you mind rewrapping?
> + of <code>-finline-insns</code>,
> + <code>--param max-inline-insns-single</code>
> + and <code>--param max-inline-insns-auto</code> needs to be re-tested.</li>
^^^
"need" (plural), and perhaps "reconsidered" instead of "re-tested"?
> + <li><code>--param max-inline-slope</code>
> + and <code>--param min-inline-insns</code>
> + has been removed; they are not needed for new bottom-up inlining
> + heuristics.</li>
"have been removed"
"for the new bottom-up inlining..."
> + <li>Unit at a time compilation mode has several compatibility issues:
"The new unit-at-a-time compilation scheme...."
> + <li>Function, variable and top-level asm statements order is changed now.
"The order in which functions, variables, and top-level
<code>asm</code> are emitted may have changed."
> + Code relying on some particular ordering needs to be updated. Majority
> + of such top-level asm statements can be replaced by section attributes.
"The majority of top-level asm statements..."
> + <li>Unreferenced static variables and functions are removed.
> + This may result in undefined references when asm statement is referring
> + to the variable/function directly.
"when an <code>asm</code> statement directly refers..."
> + Either the variable/function shall
> + be listed in asm statement operand or in the case of top-level asm
> + statements the attribute <code>used</code> shall be used to force
> + function/variable to be always output and considered as a possible
> + entry point to the unit.
"In that case, either the..."
Entry point? What does that mean in this context?
> + For variables the attribute is accepted only by GCC 3.4 and newer, while
> + for earlier versions it is sufficient to use <code>unused</code> to
> + silence warning about variable not being referenced. The preprocessor
^^^
"warnings"
"the variable not being referenced"
> + needs to be used for code portable across different GCC versions.
"To keep code portable across different GCC versions, you can use
appropriate preprocessor conditionals."
> + <li>Static functions now can use non-standard passing conventions that may
> + break asm statements calling functions directly. Again the attribute
<code>asm</code>
> *** 54,65 ****
> <li>Coverage file format has been redesigned.</li>
> <li><code>gcov</code> coverage tool has been improved.</li>
> <li><code>make profiledbootstrap</code> available to build a faster
> ! compiler.</li>
> </ul>
> </li>
> ! <li>Inlining heuristics for C, Objective-C, C++ and Java have been
> ! improved significantly. Call graph based out-of-order inlining
> ! is now enabled by default at <code>-O2</code>.</li>
> </ul>
>
>
> --- 87,127 ----
> <li>Coverage file format has been redesigned.</li>
> <li><code>gcov</code> coverage tool has been improved.</li>
> <li><code>make profiledbootstrap</code> available to build a faster
> ! compiler.
Here you removed </li>, which is also missing for the new entries. Please
add them again, or the HTML validator will complain.
> ! Experiments made on i386 hardware shown 11% speedup on
> ! <code>-O0<code> and 7.5% speedup on <code>-O2</code> compilation of
> ! large C++ testcase.</li>
"showed an 11% speedup..."
"and a 7.5% speedup..."
"of a large C++ testcase" (possibly with a link to PR8361?
> ! <li>Value profiling enabled via <code>-fprofile-values</code></li>
"New value profiling pass..."?
> ! <li>Value profile transformations pass enabled via <code>-fvpt</code>
> ! aimed to optimize some code sequences by knowing value ranges or
> ! other fact about the operands. At the moment conversion of
> ! expensive divisions into cheaper operations is implemented.</li>
"New value profile... pass"
"This aims to optimize...by exploiting knowledge about value ranges or
other properties of operands."
"a conversion...has been..."
> ! <li>New <code>-fprofile-generate</code> and <code>-fprofile-use</code>
> ! command line options to simplify use of profile feedback.</li>
"the use"
> ! <li>New unit at a time compilation mode for C, Objective-C, C++ and Java enabled via
> ! <code>-funit-at-a-time</code> (implied by </code>-O2</code>).
"A new unit-at-a-time...which is enabled by... (and implied by...)."
> ! this mode whole file is parsed first and optimized later. Following
> ! basic inter-procedural optimizations are implemented:
"The following"
> ! <li>Removal of unreachable functions and variables</li>
Not completely. I'll sortly send a bug report. :-)
> ! <li>Discovery of local functions (functions with static linkage and whose address
> ! is never taken)</li>
Omit "and"
> ! <li>On i386, the local functions use register passing conventions</li>
Full stop at the end.
"these local functions"
"register parameter passing conventions"?
> ! <li>Reordering of functions in topological order of call graph to enable
"of the call graph"
> ! better propagation of optimizing hints (such as stack alignment needed
> ! by function) in back end.</li>
"the back end"
> ! <li>Call graph based out-of-order inlining heuristics allowing to limit
"which allows"
> + Overall unit at a time mode cause 1.3% for SPECint2000 benchmark on i386 architecture.
"Overall, unit-at-a-time mode..."
"1.3% improvement", I hope? :-)
Should we specifiy the exact processor used for testing? (The gain may
significantly differ among members of the architecture familiy, I guess?)
> ! and </code>--param large-function-growth</code></li>
Full stop.
Gerald