<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 12:48 PM, Manuel Jacob <span dir="ltr"><<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-04-18 18:19, David Majnemer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It comes down to observability.  It's fine to store poison into a memory<br>
location and load it back; however, the optimizer is free to delete stores<br>
of poison.  What is not ok is depending on the value of a load of a poison<br>
value in code which may have observable results (volatile, system calls,<br>
etc.).<br>
</blockquote>
<br></span>
Thank you for the clarification.<br>
<br>
To take up the initial question, is trapping OK when a non-volatile store stores a poison value?</blockquote><div><br></div><div>No because that would result in reg2mem introducing traps where none existed before.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Apr 18, 2016 at 11:18 AM, Manuel Jacob <<a href="mailto:me@manueljacob.de" target="_blank">me@manueljacob.de</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[This mail could be an answer to the other responses as well, as they<br>
basically are the same.]<br>
<br>
Ah, I think I understand now what poison is for.  Adds are defined to not<br>
have side-effects, so the dependence rule is needed so the optimizer is<br>
allowed to exploit undefined behavior.  Is this correct?<br>
<br>
I forgot to mention in my original mail that our trapping arithmetic<br>
operations are fully speculable.  This means that the trap won't happen<br>
until the result is e.g. stored to memory.  A bit like poison values in<br>
hardware.<br>
<br>
Something is still unclear to me: while, according to the examples in<br>
LangRef, a volatile store has undefined behavior when a poison value is<br>
stored, this seems to not be true in case of non-volatile stores.  Can<br>
someone clarify please?<br>
<br>
<br>
On 2016-04-15 19:44, John Regehr via llvm-dev wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
No, trapping is not allowed, since an overflowing add nsw is defined<br>
to produce a poison value, which sort of explodes into undefined<br>
behavior if it reaches a side-effect.  This is to support speculative<br>
execution.<br>
<br>
If you emit trapping adds for nsw, you'll see spurious traps every now<br>
and then.<br>
<br>
There's a stronger form of undefined behavior, exhibited by things<br>
like divide by zero, that permits traps.<br>
<br>
John<br>
<br>
<br>
<br>
On 4/15/16 7:28 PM, Manuel Jacob via llvm-dev wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
In our backend, we currently emit add operations that trap on overflow<br>
if the IR operation has the nsw flag set.  Is this allowed?<br>
<br>
According to the documentation about poison values, overflowing a nsw<br>
add is undefined behavior.  However I didn't find a formal definition of<br>
undefined behavior in LLVM.  Judging from previous discussions on the<br>
mailing list, there seems to be a vague line of what LLVM is allowed to<br>
do in case of undefined behavior.  Is trapping allowed?<br>
<br>
-Manuel<br>
<br>
</blockquote>
<br>
</blockquote></blockquote></blockquote>
</div></div></blockquote></div><br></div></div>