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

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.

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