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