[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

Duncan Sands baldrick at free.fr
Sun Mar 8 12:48:37 PDT 2009

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".



More information about the llvm-commits mailing list