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

[Dale Johannesen]

On Sep 9, 2008, at 12:38 PMPDT, Duncan Sands wrote:

> 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.

OK, I do not know Ada.   It seems that its...interesting...FP model  
would need more than I have suggested, at least to do a good job.

>> 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).

I'm not getting through here; perhaps "IR" is too broad.

I did not say "pow" handling should ignore rounding mode; I said we  
did not need a version of "pow" that is *not* sensitive to rounding  
mode, and therefore this property did not need to be represented in  
the .bc file (although apparently this is not true for Ada).  The BE  
does obviously need to know what the properties of the intrinsics are.

As for errno, the fact that Linux uses it is a target property and  
again it does not belong in the .bc file.  That is, we do not need  
errno and non-errno versions of the intrinsics.  (Do you know any real  
code that uses errno btw?  I've never seen it outside test suites, and  
it's generally recognized as a poor design.)

>> 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.

I know, and I'm going along with it, with serious misgivings.  In what  
way do you think we don't have this?