[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]

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)?

> >  Also, a memcpy/memmove of i33 may not the same as a load+store, due  
> > to
> > the extra bits off the end (load of an i33 is only defined if the  
> > original
> > 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.

How is the size measured?  By getTypeSizeInBits, getTypeStoreSizeInBits
or getTypePaddedSizeInBits?  The first one is ok, the others not.

Ciao,

Duncan.