[llvm] r221318 - Analysis: Make isSafeToSpeculativelyExecute fire less for divides

[David Majnemer]

On Sat, Nov 8, 2014 at 10:23 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> >>> I'm pretty sure the LangRef has a bug here.  It cannot literally mean
> >>> undefined behavior or the program hits UB once an add nsw that produces
> >>> poison is used as the operand to another add.
> >
> > Why is this a problem?
>
> Answering my own question (sorry for being thick the first time
> around), this is a problem because it prevents the transform "(x + 2)
> => ((x + 1) + 1)".
>
> However, how about splitting LLVM's instruction set into instructions
> that propagate poison (like add, and lshr) and instructions that trap
> on poison (like udiv, load, call and store)?  This allows us to
> optimize "t < (t + 1)" to "true" (the < is UB if (t + 1) overflows),
> allows usual reordering of exprs composed only of ops from the first
> set (I think!) and allows us to conclude that, say, a load can never
> be poison (since the store that stored poison is UB).
>


I don't think those instructions aren't the problematic ones.  To me,
select is the real deal beaker for poison.

If a poison value enters select, is the entire select poisoned?
If not, that means select can _never_ be decomposed into arithmetic because
arithmetic propagates poison.
If so, then we can only turn phi-br into select when we are sure neither
operand of select is poison.


> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141108/6d0d34a8/attachment.html>