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

Wed Sep 12 22:48:05 PDT 2012

Committed in r163774 with a tweak to use only 8 entries for memory forms
instead of 24. Thanks!

On Wed, Sep 12, 2012 at 4:34 PM, Manman Ren <mren at apple.com> wrote:

>
> Hi Craig,
>
> I added another type to MODRMTYPES:
>  * MODRM_SPLITMISC- If the ModR/M byte is between 0x00 and 0xbf, ModR/M
> byte
>  *                  divided by 8 is used to select instruction; otherwise,
> each
>  *                  value of the ModR/M byte could correspond to a
> different
>  *                  instruction.
>
> This can reduce number of entries in modRMTable from 43k to 26k.
> Let me know what you think,
>
> I also noticed that there are a lot of InstructionContexts (69 out of 186)
>  where the entries all point to the EmptyTable.
> Is it a good idea to add a separate table to say whether all entries are
> empty for a given Instruction Context and to specify the index if it is not?
>
> I don't quite get why using opcode as the first index and context
> decisions as the second will save us space unless we use two tables instead
> of a big (256x31) table.
>
> Thanks,
> Manman
>
>
> On Sep 11, 2012, at 1:19 PM, Craig Topper <craig.topper at gmail.com> wrote:
>
> Here are a couple disassembler issues that need to be fixed too.
>
> -Prefixes like REP/REPE aren't disassembled correctly. PR7709 Need some
> way to know which instructions use it as a prefix(i.e. MOVS, CMPS, etc) and
> which use it as an opcode extension.
> -The place in the opcode map where ANDSS/ANDSD would be if they were valid
> instruction should fail to disassemble. Instead they disassemble as ANDPS.
> This occurs because the prefix bytes are basically treated as don't care
> instead of being signficant to the instruction.
>
> ~Craig
>
> On Tue, Sep 11, 2012 at 11:39 AM, Manman Ren <mren at apple.com> wrote:
>
>>
>> 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
>>
>>
>>
>
>
> --
> ~Craig
>
>
>
>

-- 
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120912/46a17a9f/attachment.html>