[PATCH] D14148: [GlobalOpt] Demote globals to locals more aggressively

[James Molloy via llvm-commits]

Hi all,

Thanks for the quick response!

> This is not true if the program is not a C++ program.

Yes. It's a pretty egregious hack, and one that's been in the code since
the year dot. Tests rely on it currently and I suppose people might rely on
it when doing non-LTO builds... I'm happy removing it but the git blame
commit log suggests this was tried before and people screamed.

> Thanks for working on this! Do you have any performance number?

Embarassingly, not all our test suites work with LTO yet so I don't have
performance numbers from the test-suite. I have massive improvements
(between 3% and 40%) in a third party benchmark suite that I can't mention
the name of, and I expect this to hit spec2000::gcc too as it uses plenty
of globals. Generally, older code suffering from "global soup" should get
improvements from this.

> I am not sure if these conditions are sufficient to say the function does
not recurse. Are indirect calls handled conservatively in the call graph?

My belief was that yes, the CallGraph does indeed model indirect calls
(specifically, if a function has its address taken or is external, it will
have a special node calling it). I don't think what I have is sufficient
though - I'll update the code. I'd forgotten about the case with indirect
calls.

> I imagine this property would be useful in other optimizations as well.
>
>What about adding an LLVM attribute "norecurse" or some such?

Yes, that sounds like a good idea. Would you prefer me to hold this patch
until I have implemented this, or is it OK to press ahead with this and
swap the functionality over when the attribute is present? (adding
attributes can take a while in my experience!)

Cheers,

James



On Wed, 28 Oct 2015 at 18:00 Duncan P. N. Exon Smith via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
>
> > On 2015-Oct-28, at 09:45, Manman Ren <manman.ren at gmail.com> wrote:
> >
> > manmanren added a subscriber: manmanren.
> > manmanren added a comment.
> >
> > Thanks for working on this!
>
> +1, I think it would be great to generalize this.  Just one idea
> below...
>
> > Do you have any performance number?
> >
> >
> > ================
> > Comment at: lib/Transforms/IPO/GlobalOpt.cpp:100
> > @@ -90,2 +99,3 @@
> >     SmallSet<const Comdat *, 8> NotDiscardableComdats;
> > +    DenseMap<const Function *, bool> FunctionsKnownNotToRecurse;
> >   };
> > ----------------
> > Comments will be great.
> > It is a little strange to name it "FunctionsKnownNotToRecurse" with a
> bool that tells if the function will recurse.
>
> I imagine this property would be useful in other optimizations as well.
>
> What about adding an LLVM attribute "norecurse" or some such?
> Assuming we can solve the indirect calls problem conservatively
> (e.g., should we be worried about function pointers escaping via
> atexit()?), this could be fairly easily propagated by an SCC pass.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151028/3d59c5ef/attachment.html>