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