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

Nick Lewycky nicholas at mxc.ca
Mon Feb 15 18:03:41 PST 2010


Jakob Stoklund Olesen wrote:
>
> On Feb 2, 2010, at 9:21 PM, Nick Lewycky wrote:
>
>> 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
>
> Thanks, it looks like Dan and Chris have already covered it.
>
> [...]
>
>> 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().
>
> Thanks.
>
> Your update to InlineCost looks fine to me, but undead instructions feeding into the condition are still counted.

They are. I didn't see an efficient way to implement it, so I didn't. 
Given that this construct will be very rare, it shouldn't change much. 
I'll be happy to fix it if there's a real-world example that it breaks 
-- or if you see a good way to add it that doesn't double-count when two 
conditional branches both lead to the same unreachable-only block.

> I would like this patch better if you would implement Chris' suggestion of DCE'ing unreachable blocks with conditions that are too gross for the optimizer. As it stands there can be arbitrarily complex instructions feeding into the condition.

No. The optimizers can't make use of the chain of information that 
unladen-swallow is planning to add. The idea is that u-s will be pinned 
to the llvm 2.7 release, and can add their own passes to the mix. That's 
fine for many things, but useless if simplifycfg is deleting our 
instructions before we get to see them. Again, we have a concrete use 
case for this.

Nick



More information about the llvm-commits mailing list