<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 9, 2016 at 9:02 AM, Benjamin Kramer via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, May 9, 2016 at 5:56 PM, Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com">nhaehnle@gmail.com</a>> wrote:<br>
> On 09.05.2016 05:19, Benjamin Kramer wrote:<br>
>><br>
>> On Mon, May 9, 2016 at 5:35 AM, Nicolai Hähnle <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
>> wrote:<br>
>>><br>
>>> Hi everybody,<br>
>>><br>
>>> I noticed today that my <a href="http://libLLVM-3.9svn.so" rel="noreferrer" target="_blank">libLLVM-3.9svn.so</a> has a ~1.7MB .<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a><br>
>>> segment<br>
>>> - i.e. data that needs to be touched by the dynamic linker even though<br>
>>> it's<br>
>>> ultimately read-only, and data that cannot be shared between multiple<br>
>>> processes using LLVM.<br>
>>><br>
>>> It turns out that a solid ~1.3MB of that data is in the tablegen'd<br>
>>> MCInstrDesc tables - there a pointers for ImplicitUses, ImplicitDefs, and<br>
>>> OpInfo that need to be relocated.<br>
>>><br>
>>> This can be fixed of course by having target-global arrays for those<br>
>>> structures referenced by MCInstrInfo (and hence TargetInstrInfo), and<br>
>>> only<br>
>>> storing offsets into those global arrays in MCInstrDesc.<br>
>>><br>
>>> The downside is that several relevant accessors need to be augmented with<br>
>>> MCInstrInfo parameters, but in the long run it seems worth it to me.<br>
>>><br>
>>> Any objections or suggestions? Is this something that people can agree<br>
>>> on,<br>
>>> i.e. do patches going in this direction have a good chance of being<br>
>>> accepted?<br>
>><br>
>><br>
>> Sounds good to me, I'm happy to accept any patch that reduces LLVM binary<br>
>> size<br>
>> without sacrificing performance. Passing MCInstrInfo isn't a big deal.<br>
><br>
><br>
> Thanks. Though note that it wouldn't affect the total binary size - instead,<br>
> it would move data from .<a href="http://data.rel.ro" rel="noreferrer" target="_blank">data.rel.ro</a> to .rodata, which means the total<br>
> binary size remains roughly the same, but more data can be directly mmapped<br>
> from disk.<br>
<br>
</div></div>Relocations also take space on disk, so there should be a reduction.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>> Is moving ImplicitUses/ImplicitDefs/OpInfo enough to get all relocs<br>
>> out of the instruction<br>
>> tables? Then the compiler could put them into a read-only section and<br>
>> we don't have to<br>
>> page them in at startup anymore.<br>
><br>
><br>
> Yes, that does the trick - I've previously done that in other places to get<br>
> reloc sizes down.<br>
><br>
> Cheers,<br>
> Nicolai<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">~Craig</div>
</div>