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

James Molloy via llvm-dev llvm-dev at lists.llvm.org
Sun Jul 17 09:34:54 PDT 2016


[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

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%)

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.



[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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160717/c6dfdd7a/attachment.html>

More information about the llvm-dev mailing list