Re: [tree-ssa] Re: PATCH: [gcc3.5 improvement branch] Very Simple constant propagation

[law at redhat dot com]

In message <20040115232858.GC25698@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >> > This patch is to address an efficiency problem in gcc.  If you 
 >> > compile the following small loop 
 >> > with -O3 -ffast-math, the optimizer converts the "a/b"  into "a * 1/b", 
 >> > in the hopes of being 
 >> > able to do some further optimizations.  In this case it can't so 
 >> > ideally  the combiner should 
 >> > convert "a * 1/b"  back into "a/b".  Unfortunately, it can't figure out 
 >> > that it can do that because 
 >> > the combiner only looks within the current basic block, and the 
 >> > constant 1 has been hoisted 
 >> > out of the loop.  This is unfortunate, because it causes an extra 
 >> > floating point multiplication to 
 >> > be performed in every iteration of this loop, which is a major 
 >> > performance hit in the code this 
 >> > originally came from.   To fix this problem, I have implemented a very 
 >> > tiny, very specific, 
 >> > very simple version of constant propagation:  It goes over the RTL 
 >> > looking for a register that 
 >> > is assigned a constant value once, and is never re-assigned another 
 >> > value anywhere in the 
 >> > instructions for the function.  For lack of a better name I called 
 >> > these "single set constants". 
 >> > Whenever I find such a Single Set Constant, I replace uses of that 
 >> > register with the constant 
 >> > value.  This is performed just before the combiner is run, and it does 
 >> > fix this problem. 
 >> > 
 >> > 
 >> > The test code for this problem is: 
 >> > 
 >> > float *a, *b; 
 >> > 
 >> > float  foo () { 
 >> >   int i; 
 >> >   float sum = 1.0; 
 >> >   for (i = 0; i < 4; i++) 
 >> >      sum *= a[i]/b[i]; 
 >> > } 
 >> 
 >> Actually this is precisely scenario that should be addressed at SSA
 >> level instead of RTL.  If we want to perform this transfromation, we
 >> probably want to do it on SSA - one can easilly compute for each DEF how
 >> many times it is used as reciprocal from SSA graph and the profile and
 >> work out if he want to do the trick.
 >> 
 >> I would suggest to simply drop this transformation completely from
 >> tree-SSA branch and work out if it is important win in some case and if
 >> we want to do it there.
 >And here is proposed patch.
 >Bootstrap/regress on i386 in progress, OK if it passes?
 >
 >Honza
 >
 >2004-01-16  Jan Hubicka  <jh@suse.cz>
 >	* expr.c (expand_expr_1): Do not convert FP division into multiplicatio
 >n
 >	by reciprocal.
Err, don't pull it out until we have the equivalent done on the SSA
optimizers.  It's hard enough to hit our performance targets without
optimizations being disabled underneath us.

jeff