[llvm-dev] RFC: Enabling Module passes post-ISel

[James Molloy via llvm-dev]

Hi Mehdi,

I've just done an LTO build of llc with debug info:
  before: 7.66GB maximum resident set size
  after:   8.05GB (+5.1%)

Cheers,

James

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[1] 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?
>
> Thanks,
>
> —
> Mehdi
>
>
> >
> > 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
> >
> > [1] 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...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160718/fcb96417/attachment.html>