[llvm-commits] [llvm] r164866 - in /llvm/trunk: lib/Transforms/Scalar/CodeGenPrepare.cpp test/CodeGen/X86/2012-09-28-CGPBug.ll

[Eli Friedman]

On Mon, Oct 22, 2012 at 12:05 PM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
>>> - Turn the dead blockaddrs into undef. I think that could work but I'm not really sure about the implications.
>>
>> Overly aggressive, given that we've already made some minor
>> concessions that blockaddr does something useful even without an
>> associated indirectbr.
>
> I think the main issue is that we have to cleanup the spec to say what
> are the guarantees we provide and update the passes to match. Right
> now the spec says one thing, but CodeGenPrepare.cpp and/or SimplifyCFG
> don't agree with it.
>
> Currently the spec says that the values is non-null and defines what
> happens when used in indirectbr. Being strict about the non-null bit
> is probably enough to say that it is illegal to replace it with undef
> (as it can be 0). From your proposal I assume you would be OK with
>
> * The blockaddress points somewhere in the current function.
> * A unused (not just indirectbr-unused) one can be deleted.
> * No guarantees are given about a indirectbr-unused label other than
> it pointing to the current function.

Basically, yes, although as a QoI issue we should try to make a
blockaddress point somewhere appropriate even if there isn't an
indirectbr.

> BTW, was there any discussion/rationale for the current semantics when
> indirectbr was introduced? Is it available somewhere?

When blockaddress was initially introduced, it was explicitly meant
only for indirectbr, hence the current spec in LangRef; I don't think
there was anything very controversial, although I might not be
remembering clearly.

Our current blockaddress stance is sort of an evolution of the
original "indirectbr-only" stance, and comes out of Chris hacking LLVM
to make the Linux kernel happy.  I don't think there was much
discussion.  See, e.g. http://llvm.org/bugs/show_bug.cgi?id=4151 .

-Eli