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

[Chandler Carruth via llvm-dev]

On Wed, Nov 2, 2016 at 5:55 PM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

But that's not how atomic vectors work -- they're atomic for the *vector*
and not for the elements!

Put differently, the atomicity is on the *operation*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161104/dba11a85/attachment.html>