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

[Peter Lawrence via llvm-dev]

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