[llvm-dev] beneficial optimization of undef examples needed

[Sanjoy Das via llvm-dev]

Hi Peter,

On Mon, Jun 19, 2017 at 7:36 AM, Peter Lawrence
<peterl95124 at sbcglobal.net> wrote:
>             You have changed the subject.  We still need real world examples

Not sure how -- I though I was pretty clear on how my answer was
related to you question.

> showing how taking advantage of “undef” results in beneficial optimization.
>
> My belief is that they don’t exist, my reasoning is this: real world programmers
> are likely to run UBSan before compiling (or if they don’t they should), therefore
> it is highly unlikely that any “undef” will actually exist during compilation of their
> source code.

The canonical example motivating undef is this:

  int a;
  boil initialized;
  if (condition) {
    a = 5;
    initialized = true;
  }
  ...
  int result = 0;
  if (condition) {
    result += a;
  }

You can't optimize the PHI node that you'll get in side the block
guarded by 'condition' to 5 without something like undef.

> Yes, “Undef” can be created during SSA construction, but we already discussed
> That in a previous email (its a register allocation problem).
>
> The only other way I can see of “undef” occurring in IR is if we go out of our
> way to optimize for example
>
>         if (   ((i64)X + (i64)Y)) < INT_MIN   ||    ((i64)X) + (i64)Y) > INT_MAX   ) {
>                 . . .
>                 Z = X  "+nsw”  Y;
>                 . . .
>         }
>
> Here “Z” could in theory be replaced with “undef”, but there is no point in doing so.
>
> Similarly with provably out-of-bounds GEP, similarly with provably invalid pointers,
> etc, but again there is no point in doing so.

These would be poison, not undef?

Just to re-iterate what I've already said before:

 - If you're willing to have both undef and poison, then you don't
need a literal representation of poison to do the kind of
transformations poison allows (e.g. A s< (A +nsw 1)).
 - However, having both undef and poison is a bad idea for several
reasons outlined in the paper.
 - Since we want the new poison to "fill in" for the undef too, we
need a literal representation for the new poison to addresses cases
like the PHI node case above.

We don't care about optimizing code that actually has undefined
behavior -- we only care about optimizing code *under the assumption*
that it does not have UB.  Both the old undef and the new poison have
been carefully designed to address this use case.

> So is there any other way of having “undef” appear in the IR ?

Loading from uninitalized memory is another way you can have undef
appear in the IR today.

-- Sanjoy