[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
clattner at apple.com
Sun Mar 8 11:41:47 PDT 2009
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.
> Also, a memcpy/memmove of i33 may not the same as a load+store, due
> the extra bits off the end (load of an i33 is only defined if the
> value was stored using an i33 store - this way we can assume any
> extra bits
> are zero, because the store puts zero there; if someone wanted to
> avoid this
> undefinedness they might have used memcpy/memmove).
This is converting a memcpy to a load/store of the same size, so it
must be a multiple of a byte in size.
More information about the llvm-commits