[llvm-dev] generated HWEncoding based register decoders

[Mike Stump via llvm-dev]

Is there any reason why we can't generate HWEncoding based decoders for registers for mc disassemblers?

This is a concept patch to explore wether it'd work, and for my target, it does the right thing.  I have one case where I have to shift a field over 2 bits, but I handle that in the glue.  If I had a HWEncoding encoding on a per register class basis, I could have made it work without the extra shift.  I have 8 register classes across 5 register files, so the code can handle at least a little complexity.

I work at silicon design time, and we update registers like people wash their hair.  Having the tool auto generate most all that I need saves me the time and complexity to keep these up-to-date as we change the design.  I suspect others might find register decoding useful.  Some ports are so trivial that they can use register class ordering to decode.  Another possibility is to reject the patch as a bad idea, and deprecate HWEncoding entirely and recommend people write their register class in encoding order, and use other means to change the allocation order.  That might be a better way to do this.  I started out with HWEncoding based post, then discovered there was no decoder; maybe that was just wrong?

I'd be interested in hearing what others might recommend (ditch HWEncoding?), and if people find the direction the patch does, in collaborating with someone if they want to finish off the patch.  Open questions, always generate tables, even if a target doesn't use HWEncoding?  Generate by default, or hide all the new routines unless someone asks for them?  Move the code into the Disassembler generator out of the RegisterInfo generator?

Thoughts?

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gendecode.diffs.txt
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170209/2eda130d/attachment.txt>