[llvm-dev] Removing pointers from MCInstrDesc for less relocations

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Mon May 9 10:28:23 PDT 2016


You'll also be changing from storing pointers in the tables to storing
offsets. This will reduce the size of the table on a 64-bit build.

On Mon, May 9, 2016 at 9:02 AM, Benjamin Kramer via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Mon, May 9, 2016 at 5:56 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> > 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.
>
> Relocations also take space on disk, so there should be a reduction.
>
> >
> >> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>



-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160509/2f45672e/attachment.html>


More information about the llvm-dev mailing list