[llvm-dev] The undef story

[Chandler Carruth via llvm-dev]

On Thu, Jun 29, 2017 at 12:18 PM Peter Lawrence <peterl95124 at sbcglobal.net>
wrote:

> On Jun 29, 2017, at 10:38 AM, Sanjoy Das <sanjoy at playingwithpointers.com>
> wrote:
>
> Hi Peter,
>
> On Thu, Jun 29, 2017 at 8:41 AM, Peter Lawrence
> <peterl95124 at sbcglobal.net> wrote:
>
> Here’s another way to look at it, no one has ever filed a bug that reads
> “I used undefined behavior in my program, but the optimizer isn’t taking
> advantage of it”
> But if they do I think the response should be
> “you should not expect that, standard says nothing positive about what
> undefined behavior does"
>
>
> Of course no one would file such a bug (since if your program has UB,
> the first thing you do is fix your program).  However, there are
> plenty of bugs where people complain about: "LLVM does not optimize my
> (UB-free) program under the assumption that it does not have UB"
> (which is what poison allows):
>
>
> Sanjoy,
>             I copied the bug reports below for reference.
>
> The way I read the first report is that the reason this problem exists
> today is the
> existence of “poison” in the LangRef, IE. we have to call
> isSCEVExprNeverPoison()
> which returns true in this case.
>
> So this is a reason to not have “poison”, “poison” is not enabling anything
> here, it is actually making it harder to do this optimization.
>
> This entire problem disappears in the alternate proposal
> (Fix “undef”, delete “poison” and “freeze”, no hoisting of nsw attributes)
> because the function isSCEVExprNeverPoison() would be deleted.
>

I just want to point out that this comment is totally true and well
understood. I don't think you need to keep repeating it.

Your alternative proposal makes some things simpler, but makes other things
harder (speculation of arithmetic) as has been pointed out by Sean and
others. It is a tradeoff.

However, reiterating one side of this tradeoff doesn't help make progress.
Given that others feel the other side of the tradeoff is better, you should
be providing data and evidence to support why yours will be better. As
several people have said already, I suspect the only way to do this is to
implement your idea and show the results.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170629/367ecbb5/attachment.html>