[llvm-dev] RFC: Enabling Module passes post-ISel
James Molloy via llvm-dev
llvm-dev at lists.llvm.org
Mon Jul 18 02:23:47 PDT 2016
I've just done an LTO build of llc with debug info:
before: 7.66GB maximum resident set size
after: 8.05GB (+5.1%)
On Mon, 18 Jul 2016 at 01:15 Mehdi Amini <mehdi.amini at apple.com> wrote:
> > On Jul 17, 2016, at 9:34 AM, James Molloy via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> > Hi,
> > [Apologies to those receiving this mail twice - used the old list
> address by accident]
> > In LLVM it is currently not possible to write a Module-level pass (a
> pass that modifies or analyzes multiple MachineFunctions) after DAG
> formation. This inhibits some optimizations and is something I'd like to
> see changed.
> > The problem is that in the backend, we emit a function at a time, from
> DAG formation to object emission. So no two MachineFunctions ever exist at
> any one time. Changing this necessarily means increasing memory usage.
> > I've prototyped this change and have measured peak memory usage in the
> worst case scenario - LTO'ing llc and clang. Without further ado:
> > llvm-lto llc: before: 1.44GB maximum resident set size
> > after: 1.68GB (+17%)
> > llvm-lto clang: before: 2.48GB maximum resident set size
> > after: 3.42GB (+33%)
> These are non-debug build, mind you trying with debug info?
> > The increases are very large. This is worst-case (non-LTO builds would
> see the peak usage of the backend masked by the peak of the midend) but
> still - pretty big. Thoughts? Is this completely no-go? is this something
> that we *just need* to do? Is crippling the backend architecture to keep
> memory down justified? Is this something we could enable under an option?
> > Any input appreciated. I can also provide a proof-of-concept patch for
> people to test if wanted.
> > Cheers,
> > James
> >  A concrete (and the motivating) example is the sharing of constants
> in constantpools across multiple functions. Two small functions that use
> the same constant must currently create their own copy of that constant.
> For many reasons that I'd not like to go into in this thread, we can't
> implement this *at all* in the current infrastructure.
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev