[llvm-dev] the root cause is CP, was: A tagged architecture, the elephant in the undef / poison room

[Nemanja Ivanovic via llvm-dev]

This may not apply at all here as I really don't understand the intricacies
of undef/poison (and especially "freeze") - I'm just following the
discussion trying to understand what the argument is.
So what I mean is that with floating point values, code within an `if (a ==
a)` condition is obviously not guaranteed to execute. Of course, you guys
aren't discussing floating point here - you're discussing integers. But it
seems to me like this type of optimization seems to treat an integer
"undef" similarly to a floating point NaN. With my very limited
understanding of the problem at hand, this seems like a logical thing.

I apologize if this is a naive view or if it distracts from the discussion.

On Mon, Jun 19, 2017 at 7:02 PM, Peter Lawrence via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Sanjoy,
>             The point is this, you have to take a stand one way or
> the other on the function-inlining issue:
>
>
> [1. this function *always* executes statement S,
>         F(a) {
>            If (a == a) S;
>         }
>    but in llvm if you inline it and “a” happens to be “undef” then nothing
> can
>    be said about whether statement S is executed. This is indefensible.]
>
>
> My belief is this: that llvm exists for a utilitarian purpose,
> and that llvm currently violates that utilitarian goal by violating
> the users expectations in the function-inlining example.
>
>
> So the question is, where do you stand ?
>
>
> Peter Lawrence.
>
>
>
> > On Jun 19, 2017, at 9:35 AM, Sanjoy Das <sanjoy at playingwithpointers.com>
> wrote:
> >
> > Hi Peter,
> >
> > On Mon, Jun 19, 2017 at 8:36 AM, Peter Lawrence
> > <peterl95124 at sbcglobal.net> wrote:
> >>            You’ve hit the nail on the head !, but I don’t think we’ve
> correctly
> >> identified the root cause of the problem yet.
> >>
> >> Rather the problem is with how we incorrectly cse and copy-propagate it:
> >>        x = undef
> >>        if (x == x)
> >>        —————>    this is an illegal copy-propagation   —————>
> >>        if (undef == undef)
> >>
> >> If you don’t believe this is illegal then we end up with the absurdity
> of the
> >> function-inlining example [1], and the argument against the
> function-inlining
> >
> > I don't think [1] is absurd.  LLVM IR is not a programming language,
> > and it is okay for it to have semantics that would seem odd in a
> > programming language.
> >
> >> example is so compelling that John decided to drop out of the argument,
> >> IE he gave up because it is indefensible.
> >
> > I think he "gave up" because he has better things to do than argue with
> you. :)
> >
> >> Apparently this copy-propagation has been justified by thinking of
> "undef"
> >> as an IR "constant” and that any optimization you can do to a “constant”
> >> can also be done to “undef” without further thought.
> >>
> >> Instead each ‘undef’ should be thought of as a live on entry register,
> IE an
> >
> > Since you're talking about "each" undef, I presume you want to have an
> > undef instruction?  As I've said before, this would be equivalent to
> > "freeze(poison)" in the new semantics.  It does not address the
> > problem of optimizing things like `a s< (a +nsw 1)` (so you'll need a
> > poison-like thing for that anyway).
> >
> >> incoming argument physical register, and “x = undef” cannot be optimized
> >> any more than “x = PhysReg0”, in particular multiple uses of X does not
> mean
> >> multiple incoming argument registers, and separate instances of “undef”
> >> cannot be equated any more than distinct incoming argument registers.
> >>
> >> To the argument that this may create unnecessary register pressure I say
> >> that is a register allocator issue not an IR issue, the register
> allocator can
> >> and should figure this out and do the right thing.
> >
> > Sure, that's a consistent proposal.  However, practically, the onus is
> > on you to prove this is reasonable from a performance standpoint.
> >
> > -- Sanjoy
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170619/53a8d152/attachment.html>