llvm dev - May 2016 - 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

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

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>