llvm dev - May 2014 - [LLVMdev] Best way to clean up empty global_ctors

I talked about this with Nick in person months ago, and my understanding is
that GlobalOpt is also an enabling optimization that needs to run early.
 For example, if we can eliminate an initializer to an internal global with
no other stores to it, we can propagate the result.

Maybe we should run it twice.


On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 30 April 2014 19:48, Nico Weber <thakis at chromium.org> wrote:
> > Hi,
> >
> > I'd like to fix PR19590, which is about llvm.global_ctors
containing
> > functions that end up being empty after optimization (which causes the
> > linker to add useless init_array entries to the output binary).
> > globalopt removes empty functions from llvm.global_ctors, but by the
> > time the function becomes empty globalopt has already run and it
> > doesn't run again.
> >
> > I'm wondering what the best fix is:
> > 1. Should globalopt run once more after all other passes have run?
> > 2. Or should the llvm.global_ctors optimization code in globalopt be
> > moved into a helper function somewhere that's called from both
> > globalopt and a new optimization pass cdtoropt that does nothing but
> > remove empty functions from llvm.global_ctors and llvm.global_dtors?
> > Then only this new pass would be added after all other passes. (This
> > new pass should run very quickly, it doesn't have to do much.)
>
> How late do you need to move globalopt to get this to work? Do you get
> any performance regressions if you just move it there?
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140501/99741a9e/attachment.html>

On 1 May 2014 14:08, Reid Kleckner <rnk at google.com>
wrote:
> I talked about this with Nick in person months ago, and my understanding is
> that GlobalOpt is also an enabling optimization that needs to run early.
> For example, if we can eliminate an initializer to an internal global with
> no other stores to it, we can propagate the result.
>
> Maybe we should run it twice.
That is probably fine, we just have to make sure compile time doesn't
surfer too much.

Cheers,
Rafael

On Thu, May 1, 2014 at 11:12 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote:
>> I talked about this with Nick in person months ago, and my
understanding is
>> that GlobalOpt is also an enabling optimization that needs to run
early.
>> For example, if we can eliminate an initializer to an internal global
with
>> no other stores to it, we can propagate the result.
>>
>> Maybe we should run it twice.
>
> That is probably fine, we just have to make sure compile time doesn't
> surfer too much.
Looking at GlobalOpt, it seems to do full symbolic evaluation of all
constructors, which is more than what's needed here. Just walking
llvm.global_ctors and removing calls to functions that are just "ret"
is all that's needed. Unless folks think that's a terrible idea,
I'll
try to write a lightweight pass for doing just that.

On 1 May 2014 11:12, Rafael Espíndola <rafael.espindola at gmail.com>
wrote:
> On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote:
> > I talked about this with Nick in person months ago, and my
understanding
> is
> > that GlobalOpt is also an enabling optimization that needs to run
early.
> > For example, if we can eliminate an initializer to an internal global
> with
> > no other stores to it, we can propagate the result.
> >
> > Maybe we should run it twice.
>
> That is probably fine, we just have to make sure compile time doesn't
> surfer too much.
>
There are many cases where another run of globalopt at the end would clean
things up.

I have a few concerns. One is that globalopt can miscompile, and I'm afraid
of making it do more or learn new tricks because that may expose its
miscompiley underbelly. The second is that a late run of globalopt opens up
all manner of new opportunities for the rest of the scalar optimizers,
which we don't run again. That's a sign that we should be designing it
differently, I just haven't thought about how exactly.

Teaching -globaldce about the ctors and dtors list sounds like a great plan
to me.

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140501/800050a7/attachment.html>