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

[Sanjoy Das via llvm-dev]

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