[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:46:49 PDT 2009

On Mar 8, 2009, at 12:44 PM, 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.
> what about trapping NaNs (maybe they're called signalling NaN's,
> I forget)?

You just get a trapping NaN in a register.  If you did an fadd on it  
you would get a trap.

>> This is converting a memcpy to a load/store of the same size, so it
>> must be a multiple of a byte in size.
> How is the size measured?  By getTypeSizeInBits,  
> getTypeStoreSizeInBits
> or getTypePaddedSizeInBits?  The first one is ok, the others not.

Padded Size.  Why do you think it isn't safe?  Have an example?


More information about the llvm-commits mailing list