This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: i386 CONST_COSTS take 2


> > this patch sets costs to 0 instead of negative values.
> > I've checked on compiling combine.c, that it basically just avoids
> > extra register used to hold "funny" constants we used previously.
> > 
> > Code size grows slightly (<1%), but I believe it to be win perofrmance wise.
> 
> The cost used to be zero before, and that caused cse to do massive constant
> propagation.  So where you said to put a 32 bit value into a variable and
> use it tren times, gcc will replicate the value ten times into the insn
> instead.  If the processor its the memory wall due to instruction fetch
> and/or i-cache pollution, that means it will go slower.
Yes, there is need for threshold.
According to the daily testing on pentium3 and Athlon, the patch setting
costs to 0 is overall win for both spec2000 and spec95 tests.  There has
been one noticeable drop in Mesa benchmark on Athlon, but otherwise it brought
considerable and consistent speedups.

On the other hand it would be nice to make costs fine grained enought to make
compiler decide thinks like "load it to register in case it is used more than
5 times".

Any ideas for implementation?

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]