[llvm-dev] beneficial optimization of undef examples needed
Sanjoy Das via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 19 09:30:19 PDT 2017
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
More information about the llvm-dev
mailing list