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

[Manman Ren]

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

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