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

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

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>

Hi Peter,

On Mon, Jun 19, 2017 at 10:02 AM, Peter Lawrence
<peterl95124 at sbcglobal.net> wrote:
>             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,
Agreed on this front.
> and that llvm currently violates that utilitarian goal by violating
You've assumed that LLVM's utility primarily lies in providing
programming-language like semantics that are obvious and easy to
program.  That isn't the case -- LLVM is a compiler framework, and its
IR semantics are only somewhat related to source language semantics.
> the users expectations in the function-inlining example.
>
> So the question is, where do you stand ?
As I said, I disagree with your characterization of LLVM's utility.

You can always write an LLVM frontend that does not generate IR that
will have this kind of "odd" semantics (in fact, I *am* a proponent of
using "safe" languages wherever possible).  However, the safety /
"obviousness" of the programming language is not directly related to
the safety / "obviousness" of LLVM IR.

-- Sanjoy

Sanjoy,
            The reason you are making a proposal
in the first place are bug reports about the compiler
compiling C/C++ programs not IR programs. 
I am simply presenting (actually Nuno came up with
the idea) another bug. It happens to be written in C.
We can translate it into IR if you prefer to discuss IR
rather than C, however it will still be the same bug.

It is time to look at this bug head on and decide how to fix it.

Peter Lawrence.

> On Jun 20, 2017, at 12:17 AM, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
> 
> Hi Peter,
> 
> On Mon, Jun 19, 2017 at 10:02 AM, Peter Lawrence
> <peterl95124 at sbcglobal.net> wrote:
>>            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,
> 
> Agreed on this front.
> 
>> and that llvm currently violates that utilitarian goal by violating
> 
> You've assumed that LLVM's utility primarily lies in providing
> programming-language like semantics that are obvious and easy to
> program.  That isn't the case -- LLVM is a compiler framework, and its
> IR semantics are only somewhat related to source language semantics.
> 
>> the users expectations in the function-inlining example.
>> 
>> So the question is, where do you stand ?
> 
> As I said, I disagree with your characterization of LLVM's utility.
> 
> You can always write an LLVM frontend that does not generate IR that
> will have this kind of "odd" semantics (in fact, I *am* a
proponent of
> using "safe" languages wherever possible).  However, the safety /
> "obviousness" of the programming language is not directly related
to
> the safety / "obviousness" of LLVM IR.
> 
> -- Sanjoy