Patch ping (some ^2)
Roger Sayle
roger@eyesopen.com
Tue May 18 06:19:00 GMT 2004
On Mon, 17 May 2004, Zdenek Dvorak wrote:
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00497.html
> PR 15274
Ok.
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00524.html
> PR 14692
Ok.
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00687.html
> simple loop analysis improvement
In implies_p,
if (mode != GET_MODE (opb0))
mode = VOIDmode;
else if (mode != VOIDmode)
;
else
{
...
}
should probably be written as
if (mode != GET_MODE (opb0))
mode = VOIDmode;
else if (mode == VOIDmode)
{
...
}
Ok for mainline with that change.
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00821.html
> speedup of compile time of expand
Ok. But I guess this no longer helps your testcase much,
now that tree-ssa places all the slots in a single list?
> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00935.html
> PR 15463
Ok.
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg01740.html
> fix for handling of reg_equal notes in simple loop analysis
Ok.
> http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00177.html
> enables unrolling of loops with <= n exit condition
Ok.
The above are all Ok for mainline. However, the remaining
three patches require either a global maintainer, or for the
"kill_redundant_phi_nodes" patch, a tree-ssa maintainer.
When posting SPEC results, could you also cut'n'paste the
geometric mean lines. This "executive summary" makes it
easier to assess whether the patch is an overall win (and its
magnitude) when the individual results contain a variety of
gains and loses. The "speculative prefetching" patch looks
good and if nobody comments this time around, I'll probably
approve it on the third ping. :> As for TSP-based BB reordering,
I don't think that GCC has any strict cost/benefit guidelines,
but this seems relatively expensive for very minor gains.
Roger
--
More information about the Gcc-patches
mailing list