[llvm-commits] patch: moving unreachable elimination to codegenprep

[Nick Lewycky]

Jakob Stoklund Olesen wrote:
>
> On Feb 2, 2010, at 8:53 AM, Nick Lewycky wrote:
>
>> This is a resurrection of the patch first discussed back in October 2009 to change the way unreachable is handled to make it live in the IR for as long as possible. The goal is to implement http://nondot.org/sabre/LLVMNotes/BuiltinUnreachable.txt in time for the LLVM 2.7 freeze so that python can make use of it when they land unladen-swallow.
>
> Nick, I couldn't find that discussion in the archives. Do you have any pointers?

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091012/089120.html

>> This patch does most of the work of just moving the time unreachables are eliminated at late as possible, currently CodeGenPrep, and updates InlineCost and SCEV to handle it. Most of the patch is just updating codegen unit tests that use the unreachable instruction.
>
> I can only comment on the InlineCost changes.
>
> It seems to me you would need to avoid unreachable instructions in the CountCodeReductionFor* methods as well. Is unreachable only found at the beginning of a block?

Unreachable is only of interest when found at the beginning of a block. 
The change is that we no longer optimize 'conditional branch to block 
starting with unreachable' to an unconditional branch to the other BB. 
The handling of unreachables in the middle of a block is unaffected by 
this patch.

> What about all the undead code driving a switch or br to unreachable? That should not be counted in the inline cost since it will eventually be eliminated.
>
>> The primary concern from last time was the side-effects of keeping the chain of computation that fed into a dead branch. The 'extra' instructions could have effects on everything from inlining to loop analysis, but any approach short of cramming the entire expression into metadata attached to the branch would have the same problem.
>
> It seems that a lot of optimizations could be sabotaged by undead code.

Sure but I'd expect that case to be rare. If an 'unreachable' is created 
by our own optimization passes then we will still delete the 
instructions that precede it, up until we reach a call with visible 
side-effects or a conditional branch.

> Do we have any measurements that show this to be a good idea in the first place?

The case we want this is in unladen-swallow where we use this for LLVM 
to perform final value replacement after a type check. After determining 
the type from type feedback, we construct IR which still needs to do 
runtime checks of the type, but once the type is validated we can assume 
things about the contents of other fields in the object.

We need a way to express this.

Jakob, I'll make the tweaks to InlineCost that you proposed and post an 
updated patch with the results of a nightly test run. Realize that I'm 
expecting no visible performance difference at all since no code in the 
nightly test uses __builtin_unreachable().

Nick