This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [wwwdocs] Update changes-3.4.html


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]