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

Evan Cheng evan.cheng at apple.com
Wed Sep 23 15:18:59 PDT 2009


Are we generating a call to sqrt now? If so, that's bad. We should be  
using SSE sqrts* instructions.

Evan

On Sep 23, 2009, at 3:12 PM, 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?
>
> 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
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list