Nicolai Hähnle via llvm-dev
2016-May-09 03:35 UTC
[llvm-dev] Removing pointers from MCInstrDesc for less relocations
Hi everybody, I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment - i.e. data that needs to be touched by the dynamic linker even though it's ultimately read-only, and data that cannot be shared between multiple processes using LLVM. It turns out that a solid ~1.3MB of that data is in the tablegen'd MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and OpInfo that need to be relocated. This can be fixed of course by having target-global arrays for those structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only storing offsets into those global arrays in MCInstrDesc. The downside is that several relevant accessors need to be augmented with MCInstrInfo parameters, but in the long run it seems worth it to me. Any objections or suggestions? Is this something that people can agree on, i.e. do patches going in this direction have a good chance of being accepted? Cheers, Nicolai
Benjamin Kramer via llvm-dev
2016-May-09 10:19 UTC
[llvm-dev] Removing pointers from MCInstrDesc for less relocations
On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote:> Hi everybody, > > I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment > - i.e. data that needs to be touched by the dynamic linker even though it's > ultimately read-only, and data that cannot be shared between multiple > processes using LLVM. > > It turns out that a solid ~1.3MB of that data is in the tablegen'd > MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and > OpInfo that need to be relocated. > > This can be fixed of course by having target-global arrays for those > structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only > storing offsets into those global arrays in MCInstrDesc. > > The downside is that several relevant accessors need to be augmented with > MCInstrInfo parameters, but in the long run it seems worth it to me. > > Any objections or suggestions? Is this something that people can agree on, > i.e. do patches going in this direction have a good chance of being > accepted?Sounds good to me, I'm happy to accept any patch that reduces LLVM binary size without sacrificing performance. Passing MCInstrInfo isn't a big deal. Is moving ImplicitUses/ImplicitDefs/OpInfo enough to get all relocs out of the instruction tables? Then the compiler could put them into a read-only section and we don't have to page them in at startup anymore.
Nicolai Hähnle via llvm-dev
2016-May-09 15:56 UTC
[llvm-dev] Removing pointers from MCInstrDesc for less relocations
On 09.05.2016 05:19, Benjamin Kramer wrote:> On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <llvm-dev at lists.llvm.org> wrote: >> Hi everybody, >> >> I noticed today that my libLLVM-3.9svn.so has a ~1.7MB .data.rel.ro segment >> - i.e. data that needs to be touched by the dynamic linker even though it's >> ultimately read-only, and data that cannot be shared between multiple >> processes using LLVM. >> >> It turns out that a solid ~1.3MB of that data is in the tablegen'd >> MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and >> OpInfo that need to be relocated. >> >> This can be fixed of course by having target-global arrays for those >> structures referenced by MCInstrInfo (and hence TargetInstrInfo), and only >> storing offsets into those global arrays in MCInstrDesc. >> >> The downside is that several relevant accessors need to be augmented with >> MCInstrInfo parameters, but in the long run it seems worth it to me. >> >> Any objections or suggestions? Is this something that people can agree on, >> i.e. do patches going in this direction have a good chance of being >> accepted? > > Sounds good to me, I'm happy to accept any patch that reduces LLVM binary size > without sacrificing performance. Passing MCInstrInfo isn't a big deal.Thanks. Though note that it wouldn't affect the total binary size - instead, it would move data from .data.rel.ro to .rodata, which means the total binary size remains roughly the same, but more data can be directly mmapped from disk.> Is moving ImplicitUses/ImplicitDefs/OpInfo enough to get all relocs > out of the instruction > tables? Then the compiler could put them into a read-only section and > we don't have to > page them in at startup anymore.Yes, that does the trick - I've previously done that in other places to get reloc sizes down. Cheers, Nicolai