[llvm-commits] [llvm-gcc-4.2] r82640 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp
dalej at apple.com
Wed Sep 23 17:19:30 CDT 2009
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,
>> 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.
>> looks like that was the original intent, actually, but that's not
>> 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.
>> 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
>>> The result of sqrt(negative) is implementation-defined, but follows
>>> IEEE754 in most current implementations. llvm.sqrt, which has
>>> behavior for such inputs, is an inappropriate substitute which can
>>> the result.
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
More information about the llvm-commits