[llvm-commits] [llvm-gcc-4.2] r55796 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

[Duncan Sands]

Hi Dale,

> Whether an intrinsic reads the rounding mode is a language property.   
> AFAIK there is no need for "pow that doesn't read rounding mode"  
> because no language has such functionality.

this is not entirely true, for example in Ada it is correct to ignore
the effect of the rounding mode for "pow", so it is output as "readnone".
The reason is that Ada uses an interval arithmetic model of floating
point calculation, not IEEE: any result in a so-called model interval
is correct.  As far as I understand it, varying the rounding mode results
in a different numerical result, but also in the model interval.  Suppose
I do (in Ada):
  a = pow (x,y)
  change_rounding_mod
  b = pow (x,y)
Then in Ada it is correct to replace "b" with "a", not because they are the
same number (they may not be) but because "a" is a valid result for the
second pow call.

> It may be that a  
> particular implementation doesn't need the rounding mode;  the BE is  
> permitted to do target-dependent optimizations if it knows that.

This is more or less the case in Ada.  It uses readnone to indicate it.

> Whether an implementation sets errno (as Darwin does not) is a target  
> dependency.  c99 does not require it.  Again a target may do target- 
> dependent optimizations if it wants.  (Of course this property may be  
> shared by many targets so some abstraction would be useful; I am not  
> saying these optimizations belong in the X86-specific code, for  
> example.)
> 
> So, I don't think it's necessary to represent either of these  
> properties in the IR as such;

I don't follow you.  On linux the "pow" standard library function
sets errno.  If my program calls "pow" and uses errno, you can't
just ignore that property of "pow".  If I'm doing careful numerics
that relies on the rounding mode, the fact that the result of "pow"
depends on the rounding mode is important and can't just be ignored.
(People who want to ignore it can use -ffast-math, which results in
a "readnone" pow).

> some abstraction such as "readnone" is  
> useful on the intrinsic definitions since there is much commonality,  
> but that would not be strictly necessary either.
> 
> If you're interested in working in this area, IMO the most useful  
> thing would be to add a real representation for rounding mode in the  
> BE.  Typically it is read by many instructions and intrinsics, and  
> changed by only a few.  Once we can deal with "reads rounding mode but  
> not memory" intelligently we can get somewhere with optimizations.

Yes, it would be useful, but as a first step I would rather have
llvm(-gcc) produce correct code, and worry about optimization later.

Ciao,

Duncan.