[llvm-commits] cxa_guard elimination

[Nick Lewycky]

Chris Lattner wrote:
> On Jan 28, 2012, at 11:50 PM, Nick Lewycky wrote:
>>> The good news is that we already have a valid DomTree by the time
>>> simplify-libcalls runs, so we're good to request one here.
>>>
>>> The updated patch is barely more complicated, there's just an additional
>>> check to see whether there's a single predecessor block that's testing
>>> the guard variable, and an additional domtree BB test (so, no linear
>>> time) on each StoreInst. No sweat!
>>>
>>> Please review! I'd like to land this patch and then start working on
>>> some of its deficiencies in follow-up patches.
>>
>> Uh... I mailed out the entirely wrong patch.
>>
>> Correct patch attached!
>
> Hi Nick,
>
> Did you consider doing this as part of globalopt?

Yes, that was the next thing in my email :) However, consider that:

- I'd like it to run *after* the inliner so that I don't get fouled up 
by constructor calls
- I'd like it to run *before (or with)* globalopt so that we can 
transform other globals (like the guard variable) that only becomes 
possible after the cxa-guard is eliminated.

There is no such place in the pipeline. We can do things like refactor 
globalopt into a utility the make cxa-guard-elim call it in its 
doFinalization() or something.

I was hoping to commit it to simplify-libcalls first to hammer out any 
correctness issues while I figure out where it should ultimately live.

Or if you ask, I can just drop it into globalopt for now and figure 
something out later?

Nick

   It already has "simulation" logic that could be reusable, and doing 
this early means that you can optimize for the common case, where 
inlining hasn't happened yet.  It seems like it would eliminate some of 
the dominator requirements, and wouldn't prevent merging 
simplifylibcalls into instcombine in the future.
>
> -Chris
>