[llvm-commits] [PATCH] TableGen: reduce the size of ContextDecision tables in X86GenDisassemblerTables

[Manman Ren]

On Sep 11, 2012, at 11:17 AM, Craig Topper <craig.topper at gmail.com> wrote:

> I changed INSTRUCTION_IDS to a uint16_t in a commit last night. Unfortunately with that value be 43K right now, you can't merge it with the modrm_type since that's 2-bits and 43K needs 16-bits by itself. I guess it might work with the indirection method you did in your patch. But again there are tons of duplicates in the modRMTable and finding a way to make those unique would provide more benefit.
You are right. There are 43k entries in modRMTable, and only 3500 entries are unique.
> 
> Personally, I think this whole structure needs to be redesigned with opcode as the first index and any context decisions behind that. We're blowing a lot of space for multiple VEX contexts for instructions that will never have VEX equivalents. And we still need to add XOP contexts for AMD which would further explode the tables.
I think it is worthwhile to check whether the whole data structure should be redesigned, given that we have lots of duplicate information stored. I will see whether it makes sense to check opcode first.

Thanks,
Manman
> 
> ~Craig
> 
> On Tue, Sep 11, 2012 at 10:07 AM, Manman Ren <mren at apple.com> wrote:
> 
> Hi Craig,
> 
> I meant this data structure:
> struct ModRMDecision {
>   uint8_t     modrm_type;
> 
>   /* The macro below must be defined wherever this file is included. */
>   INSTRUCTION_IDS 
> };
> 
> Currently, modRMTable has 43k entries, each entry is 16-bit, and we have 6 ContextDecision tables, a total of 47k entries, where each entry is a struct ModRMDecision.
> So if we reduce INSTRUCTION_IDS to 16-bit, we will reduce the size by 47k*2 bytes, and if we can further encode modrm_type and INSTRUCTION_IDS to a single 16-bit, we can save another 47k*1 bytes.
> The current size of modRMTable is 43k*2 bytes.
> 
> I assume you meant modRMTable by "the ModRM decision table".
> 
> Thanks,
> Manman
> 
> On Sep 10, 2012, at 7:17 PM, Craig Topper <craig.topper at gmail.com> wrote:
> 
>> I don't follow how you would merge modrm_type and instructionIDs as those fields are in different tables.
>> 
>> On Mon, Sep 10, 2012 at 7:12 PM, Manman Ren <mren at apple.com> wrote:
>> 
>> Yes, I noticed that the max value is 43459 after I spent the effort to add an encoder :(
>> But we can potentially combine the modrm_type with instructionIDs to fit into a single 16-bit number, thus saving 8-bit for each entry.
>> 
>> Let me know whether that is worth a try.
>> 
>> I will look into how to uniquely the ModRM decision table if possible. Do you have specific suggestion on how to?
>> 
>> Thanks,
>> Manman
>> 
>> On Sep 10, 2012, at 7:09 PM, Craig Topper <craig.topper at gmail.com> wrote:
>> 
>>> Far as I can tell there's no reason you can't just change the existing index to 16-bits. The largest index is 43459. I'd rather to see effort spent uniquifying the ModRM decision table which will provide a much larger bang.
>>> 
>>> On Mon, Sep 10, 2012 at 12:28 PM, Manman Ren <mren at apple.com> wrote:
>>> 
>>> TableGen: reduce the size of ContextDecision tables in X86GenDisassemblerTables
>>> by adding an encoder for instructionIDs. The main motivation is that in 83% of
>>> the cases, the value is zero, so we should be able to use a 16-bit index
>>> into the encoder and the encoder will translate the index into the actual
>>> 32-bit value.
>>> 
>>> Later on, we may combine the modrm_type with instructionIDs to fit into a single
>>> 16-bit number.
>>> 
>>> The size of libLTO in a Release build is reduced by 200k. The downside is one
>>> more memory access to the encoder when decoding the instruction ID.
>>> 
>>> Thanks for reviewing the patch! Comments are greatly appreciated.
>>> 
>>> Manman
>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> ~Craig
>> 
>> 
>> 
>> 
>> -- 
>> ~Craig
> 
> 
> 
> 
> -- 
> ~Craig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120911/a220c1ef/attachment.html>