[llvm-commits] cxa_guard elimination

Nick Lewycky nicholas at mxc.ca
Thu Feb 9 00:56:46 PST 2012


Nick Lewycky wrote:
> 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

Of course GlobalOpt is interprocedural, since it already has to not be 
fouled up by constructor calls.

Updated patch attached, including more bugfixes than ever before! Please 
review!

Nick

> - 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
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: globalopt-cxa_guard-1.patch
Type: text/x-diff
Size: 37952 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120209/2b1e9c4f/attachment.patch>


More information about the llvm-commits mailing list