[llvm-commits] [llvm] r66366 - in /llvm/trunk: lib/Transforms/Scalar/ScalarReplAggregates.cpp test/Transforms/ScalarRepl/2008-06-22-LargeArray.ll test/Transforms/ScalarRepl/vector_memcpy.ll

Nate Begeman natebegeman at mac.com
Sun Mar 8 12:25:15 PDT 2009

On Mar 8, 2009, at 11:55 AM, Eli Friedman wrote:

> On Sun, Mar 8, 2009 at 10:41 AM, Chris Lattner <clattner at apple.com>  
> wrote:
>> On Mar 8, 2009, at 3:36 AM, Duncan Sands wrote:
>>> Hi Chris,
>>>> +    // If this is a memcpy or memmove into or out of the whole
>>>> allocation, we
>>>> +    // can handle it like a load or store of the scalar type.
>>> a load+store of a floating point type might trap, while a memcpy/
>>> memmove would
>>> not.
>> How so?  Load of double works on any bit pattern, so long as the
>> address is correct and the alignment is right etc.
> That's not true for x87 FP: SNaNs either crash or get silently changed
> into QNaNs, depending on the control word.  I haven't read the code
> carefully enough to see whether that applies here, though.

I guess the question is, is that also the behavior that we want for  
LLVM IR?  I'm not sure the body of existing code which depends on  
trapping on an x87 SNaN load is large enough or important enough to  
automatically rule out this transformation.


More information about the llvm-commits mailing list