[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?
-Chris
More information about the llvm-commits
mailing list