[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

Chris Lattner clattner at apple.com
Sun Mar 8 12:54:11 PDT 2009

On Mar 8, 2009, at 12:48 PM, Duncan Sands wrote:

> Hi Nate,
>>>>> 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.
> x86 has other problems when copying using floats.  This came up in  
> llvm-gcc,
> see http://llvm.org/PR2680  Quoting from the bug report "Bottom  
> line, 387 FP
> copies can't be relied on to do bitwise copies".

The patch for that bug changed copies to happen in integer registers.   
Do you have an example that would illustrate this problem?


More information about the llvm-commits mailing list