<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Nov 2, 2016 at 5:55 PM Philip Reames via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    <p class="gmail_msg"><br class="gmail_msg">
    </p>
    <br class="gmail_msg">
    <div class="m_7246031264459326151moz-cite-prefix gmail_msg">On 10/21/2016 01:53 PM, Nuno Lopes via
      llvm-dev wrote:<br class="gmail_msg">
    </div>
    <blockquote type="cite" class="gmail_msg">
      <blockquote type="cite" style="color:#000000" class="gmail_msg">
        <pre class="gmail_msg">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.
</pre>
      </blockquote>
      <pre class="gmail_msg">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.
</pre>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000" class="gmail_msg">
    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),</div></blockquote><div><br></div><div>But that's not how atomic vectors work -- they're atomic for the *vector* and not for the elements!</div><div><br></div><div>Put differently, the atomicity is on the *operation*.</div></div></div>