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

[Philip Reames via llvm-dev]

On 10/21/2016 01:53 PM, Nuno Lopes via llvm-dev wrote:
>> Auto-vectorization, converting adjacent scalar memory accesses into vector accesses, or into wider combined scalar accesses is a concern. If widening a load causes it to read a poison that it didn't previously read, and if the value is subsequently stored, this would put poison in more individually addressable places than in the original program, so it could inject UB into a program that didn't previously have it. This is related to the memcpy topic that's been raised.
> The problem with widening Is already there today. We are not really changing the semantics of poison, just creating more opportunities for it to appear.
> We have a solution for widening, which is to use vectors. Since we define poison at value-level, we can widen, say, a "load i32" into "load <2 x i32>" (but not to "load i64").  One may argue that this representation is even better, since it actually exposes the fact that we are loading multiple, independent values.  But we need to make sure the rest of LLVM pipeline is fine with increased usage of vectors throughout.
Specifically to this point, we have independent reasons to prefer a 
vector representation for a set of widened loads.  Specifically, if the 
loads in question are atomic, we need to be able to represent the 
individual elements' atomicity (as opposed to the widened widths 
atomicity), if we want a chance to reverse the transformation later.  If 
widening is to be a canonicalization at the IR level, being able to 
reverse it is a must.

Worth noting though is that this doesn't stop with vectors.  It might 
very well be worthwhile to widen a pair of adjacent i8 loads with a 
adjacent i16 load.  The same argument which leads us to wanting to 
preserve the elements of the vector, would now lead us directly to 
structs being a first class IR construct.  And we do love FCAs don't we?  :)

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161102/178e08c8/attachment.html>