<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 10/21/2016 01:53 PM, Nuno Lopes via
llvm-dev wrote:<br>
</div>
<blockquote cite="mid:018201d22bdd$3b74c1c0$b25e4540$@ist.utl.pt"
type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">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 wrap="">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>
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.<br>
<br>
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? :)<br>
<br>
Philip<br>
</body>
</html>