(If this thread is becoming tiresome, let me know. This newbie is trying to<div>understand some of what's going on; clearly you've thought about it way more</div><div>than I have, and I can understand if you want to stop thinking about it!)<br>
<br><div class="gmail_quote">On Mon, Dec 5, 2011 at 2:22 PM, Dan Gohman <span dir="ltr"><<a href="mailto:gohman@apple.com">gohman@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">On Dec 5, 2011, at 11:55 AM, Paul Robinson wrote:<br>
><br>
> On Thu, Dec 1, 2011 at 9:37 AM, David A. Greene <<a href="mailto:greened@obbligato.org">greened@obbligato.org</a>> wrote:<br>
> Dan Gohman <<a href="mailto:gohman@apple.com">gohman@apple.com</a>> writes:<br>
><br>
> > Prohibiting poison values from propogating through memory would mean<br>
> > that the reg2mem pass would no longer be a semantics-preserving pass.<br>
><br>
> Or it means you couldn't demote those values.<br>
><br>
> If reg2mem is constructing spill slots, or address-not-taken locals, I could<br>
> see classifying those as okay-to-poison. You would not want statics or globals<br>
> or pointer-addressed memory to be poisonable, as those should be treated<br>
> as being observable locations.<br>
><br>
> So, it's not really "all of memory" that could be poisoned, only these<br>
> compiler-generated things.<br>
<br>
</div></div>This would mean that it's not valid to do store-to-load propagation<br>
in the optimizer if the pointee might be a global variable. That<br>
would mean the loss of real optimizations.<br>
<br>
And it would still mean that non-volatile store instructions suddenly<br>
can have side effects beyond just writing to their addressed memory.<br>
That would be surprising.<br>
<br>
I think Dave also suggested making select instructions be<br>
observation points. That would mean that select instructions would<br>
have side effects. Again, that would be surprising.<br>
<font color="#888888"><br>
Dan<br>
<br>
</font></blockquote></div><div>Back in your first message on this thread, you did say:</div><div><br></div><div>>The poison would</div><div>>propagate down the def-use graph until it reaches an instruction that</div>
<div>>is capable of triggering the undefined behavior.</div><div><br></div><div>So, somebody somewhere has to be capable of triggering the undefined</div><div>behavior. What instructions did you have in mind? If the store,</div>
<div>select, and compare instructions aren't appropriate, which ones are?</div><div><br></div><div>I don't think this next suggestion was on your list, so here goes:</div><div>Drawing from the Itanium example, we could define a new 'check' </div>
<div>instruction, which would explicitly trigger the undefined behavior if its</div><div>operand is poisoned, or produce a known-safe value otherwise. Yes, the</div><div>IR would have to be sprinkled with these things; but only outputs of 'nsw'</div>
<div>kinds of operations would subsequently need a 'check' to sanitize them.</div><div><br></div><div>So, if a potentially poison value propagates down the def-use graph</div><div>until it reaches a store/select/compare, that instruction must be </div>
<div>preceded by a 'check' that will sanitize the value.</div><div><br></div><div>(Or maybe we should call it the 'foodtaster' instruction, which protects</div><div>the important instructions from poison...)</div>
<div><br></div><div>Separating out the induce-undefined-behavior instruction means the</div><div>existing semantics of store/select/compare are unaffected, the main</div><div>consequences being that you can't move these guys past the 'check'</div>
<div>that feeds them.  But that constraint would exist automatically anyway,</div><div>right? because you couldn't move an instruction up prior to where its</div><div>input values are defined.</div><div><br></div><div>
Clever/optimal placement of 'check' becomes a topic of interest, but</div><div>that's kind of the point of the exercise.</div><div><br></div><div>Pogo</div><div><br></div></div>