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]
Other format: [Raw text]

Re: elliminate more float extensions


> Jan Hubicka wrote:
> > 
> > Hi,
> > I've been looking for reasons of cvtss2sd (that is slow) in mesa sources and it
> > looks like that after installing floor conversion patches to hammer branch most
> > of these come from testcases like this:
> > 
> > /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
> > /* { dg-options "-O2 -msse2 -march=athlon" } */
> > /* { dg-final { scan-assembler-not "cvtss2sd" } } */
> > float a,b;
> > main()
> > {
> >   a=b*3.0;
> > }
> > 
> > We can optimize the cvtss2sd away.  I am doing this by teaching strip_float_extensions
> > to find narrowest mode holding the FP constant so the rest of code will choose
> > narrowest mode holding the operands and result of the operation.
> 
> Does this always work correctly?  Consider:
> 
> 	float aiee(float a, float b)
> 	{
> 		return a * 3.0 * b;
> 	}
> 
> 	int main()
> 	{
> 		aiee(2e+38f, 0.1f);
> 	}
> 
> This will overflow if the (a * 3.0) is calculated in single precision.
> 
> People who care about optimization at this low level should know to
> write  3.0f  when they want it, imho.

Optimization won't happen in this case, as 3.0*b will not be casted to
single precision immediately.
Unforutnately pepople often forget to write the 'f' suffix and in 3d
programs the conversions are surprisingly common (Mesa spends about
8-15% time in conversions for instance)

Honza
> 
> 
> Segher
> 
> (The CMP and ABS/NEGATE patches look safe to me, btw).
> 


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