[wwwdocs] more updates to gcc-3.4/changes.html

Vladimir Makarov vmakarov@redhat.com
Tue Jan 6 23:21:00 GMT 2004


Jan Hubicka wrote:
> 
> !     <li>Web construction pass enabled via <code>-fweb</code> (and implied by
> !       <code>-O3</code>) improve quality of register allocation, CSE
> !       and some other optimization passes by avoid re-use of pseudo registers
> !       with non-overlapping live ranges.  The pass almost always improve
> !       code quality but does make debugging difficult and thus it is not
> !       enabled by default by <code>-O2</code>
> !       <p>The pass is especially effective as cleanup after code duplication
> !       passes, such as loop unroller or the tracer.</p></li>

  Unfortunately for me, I've written the same optimization several
months ago
and just waited when mainline is at the stage 1 to commit the
patch.  My major difference is in that I placed it right before
register allocation.  You were quicker to commit it.  Was it written in
2001/2002?  I found it in title of web.c.  Although I see it was
committed in November 2003.

  I had mixed experience with the optimization.  E.g. perlbmk for P4
has much worse result with this optimization.  But this is mainly of
global register allocation drawbacks (50% of the benchmark is spent in
one function regexp matching -- on my opinion the benchmark should
have named as regexp.  A global pseudo register living through
function gets hard register without the optimization and it is better
than some pseudo-registers created from the global pseudo-register get
memory).

  But in overall this optimization is good for x86 because more values
lives in registers (it also results in that code size for x86 with this
optimization is usually smaller).  This option is a good candidate for
Scott Ladd's benchmarks (huffbench was sped up 20% for P4).

  The optimization creates much more parallelism for the 1st insn
scheduler because it removes many anti-dependencies.  So it should be
definitely used for Itanium processors especially for scientific
programs (e.g. SPECFP2000 sixtrack became 17% faster).  On the other
hand, it might give worse results for processor with small or medium
register files because more freedom in rearranging insns results in
more probability of unwilling register spills which could be avoided.
Even some SPECFP2000 tests have worse results because an excessive
register pressure after the 1st insn scheduling.

Vlad



More information about the Gcc-patches mailing list