inadequate multiply-by-const expansion for pentium4

[Luchezar Belev]

Jim Wilson wrote:
> Luchezar Belev wrote:
> > I played a bit to see how gcc expands multiplication by various constants in
> > leas/adds/subs/shifts and found that it does not do the job in the best possible
> > way it could. I tracked for the the reason and found 3 different problems:
> 
> We don't track messages sent to the gcc mailing list.  Maybe someone 
> will look at this, maybe not.  You might want to submit a bug report for 
> this, so the ideas don't get lost.  Or you can try fixing them yourself.

Ok, but strictly speaking this is not a bug since the compiler isn't doing
someting unallowable (like ICE-ing or generating invalid code).
That's why I thought that a bug report would be inappropriate for this matter.

Is it really acceptible to fill bug reports for such kind of issues?

> >  1) the cost of an add insn for p4 (in config/i386/i386.c) is 1 while
> >     it should be 0.5 (or probably 1 with all other costs doubled)
> 
> The costs are relative to other costs.  Doubling the costs may not work. 
>   And since the cost has to be an integer here, using 0.5 won't work either.

up to gcc-3.3.3 the costs of the non-add instructions were doubled, but
in gcc-3.4.0 for some reason this was rejected.
 
> >  3) look at the followind code in gcc/expmed.c, expand_mult():
> >       mult_cost = rtx_cost (gen_rtx_MULT (mode, op0, op1), SET);
> >       mult_cost = MIN (12 * add_cost, mult_cost);
> 
> This looks like a pragmatic code expansion limit.  If given a choice 
> between emitting 13 adds or a single multiply, we choose to emit a 
> single multiply even if the latency is longer, to avoid unreasonable 
> code size expansion.  13 adds may be slower due to cache effects for 
> instance, even if the latency figures show that they may be faster.  It 
> might be reasonable to change this limit depending on optimization 
> options.  Or maybe compute the limit differently, for instance 6 * 
> add_cost + 6 * shift_cost instead of just 12 * add_cost.

Why to avoid code size expansion when using -O3 or higher? Taking it's potential
speed gain into account, it's probably not less reasonable than the
loop unrolling or function inlining (the same is true for the cache effects).
At least this limit could be done in some architecture-dependent maner and
tuned more precisely acording to the arch specifics.
 
> In general, performance on a testsuite (like SPEC) will be more 
> convincing than simple multiply sequences in isoation.  In real 
> programs, a multiply usually does not occur by itself, so you have to 
> consider how the sequence performs when scheduled with other 
> instructions.  Sequences that look optimal in isolation may cause real 
> programs to run slower because of scheduling, cache, or other effects.

I think that a group of instructions with lower total latency always have
better chance for good scheduling than single instruction with higher latency
because you always can just put them together in the place of the single insn,
but you can also shuffle them with the other instructions and further hide latencies.

Lucho



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover