This is the mail archive of the
mailing list for the GCC project.
Re: How to avoid de-optimization
- To: pfk at fuchs dot offl dot uni-jena dot de, gcc at gcc dot gnu dot org
- Subject: Re: How to avoid de-optimization
- From: Jan Hubicka <jh at suse dot cz>
- Date: Sun, 26 Aug 2001 10:13:21 +0200
Actually the MUL->arithmetic converison is controlled by costs information
near the beggining of i386.c file and is CPU model specific.
For instance K6 cost is 3, while cost of simple operation is 1. This means
that gcc will replace mul by one, or two simple operations.
I Athlon case it is set to 5, pentiumII 4 and Pentium4 30. Always representing
the relative latency of simple arithmetic compared to imul instruction.
In what CPU are you experiencing slowdown?
And yes, when optimizing of the size, the costs should be rescaled to represent
instruction length. I will do that today.