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

[Dale Johannesen]

On Sep 23, 2009, at 3:12 PMPDT, Evan Cheng wrote:

>
> On Sep 23, 2009, at 2:18 PM, Dale Johannesen wrote:
>
>> While this is certainly necessary given the current IR definition,  
>> I'm
>> not too happy about it, as we will lose something because the
>> optimizers must consider that sqrt might set errno.  What I'd like to
>> do is redefine llvm.sqrt in the IR to mean "same behavior as sqrt
>> except that it doesn't set errno", and likewise for llvm.pow, etc.   
>> It
>> looks like that was the original intent, actually, but that's not  
>> what
>> it says.  Any objections?
>
> Are we doing any optimizations on llvm.sqrt?

It's known to be readonly, while sqrt is not (which I'm sure was the  
point of having it).
Beyond that, it's "optimizing" sqrt(negative) to 0 in ConstantFoldCall  
and perhaps other places.   I'd like to get rid of that, but it seems  
permissible under the current definition.

> Evan
>
>>
>> On Sep 23, 2009, at 11:50 AMPDT, Dale Johannesen wrote:
>>
>>> Author: johannes
>>> Date: Wed Sep 23 13:50:32 2009
>>> New Revision: 82640
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=82640&view=rev
>>> Log:
>>> The result of sqrt(negative) is implementation-defined, but follows
>>> IEEE754 in most current implementations. llvm.sqrt, which has
>>> undefined
>>> behavior for such inputs, is an inappropriate substitute which can
>>> change
>>> the result.
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>