[llvm-dev] RFC: Killing undef and spreading poison

[Nuno Lopes via llvm-dev]

> I'm still digesting the proposal in its entirety, but one point I want to call out here:
>
>> On Tue, Oct 18, 2016 at 1:39 PM Friedman, Eli via llvm-dev wrote:
>> Instcombine currently transforms "memcpy(dst, src, 4)" to "load i32 src;
>> store i32 dst".  I guess that's illegal under this model?  How about the
>> related transform "memcpy(dst, src, 4)" to "load <4 x i8> src; store <4
>> x i8> dst"?  (SROA also performs similar transforms.)
> 
> I think it is really important that memcpy and load/store pair be equivalent. If this is in fact true about the proposal, I would want to really dig into why and whether anything could be done to make them equivalent.

Memcpy does a byte-by-byte copy. So if one of the bits is poison then only the byte containing that bit becomes poison.
Therefore, memcpy(x, y, 1) is equivalent to load i8.  But memcpy(x,y,4) is not equivalent to "load i32" since load makes the whole value poison if any of the bits is poison.
The alternative as given by Eli is to use "load <4 x i8>".  Since now we are loading 4 separate values, poison does not extend past the byte boundary.  When load is lowered, you should get exactly the same code as with "load i32", though.
So the hope is that there's no diff at assembly level.

We were supposed to be doing this already btw; there's no change regarding poison semantics for load/store. LLVM is risking miscompilation ATM (when doing this memcpy -> load/store transformation).

Nuno