[llvm-dev] generated HWEncoding based register decoders

[Alex Bradbury via llvm-dev]

On 10 February 2017 at 18:59, Mike Stump via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Feb 10, 2017, at 6:58 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>> I'm against using implicit ordered in the TableGen file to generate the hardware encoding numbers. This would lead to unnecessary gymnastics assuming it were usable at all.
>
> Ports do that today.  The problem with doing that is that it is easy for the encode/decode to be mismatched.  I already did that and burned time discovering that.  Lanai does this for example, as do others.  I'd love to see people migrate away from that method to one that always just works as then a new port writter can copy any of the ports and never suffer the it doesn't just work problem I faced.
>
>> Moving the code to the disassembler generator makes sense, although at least on PowerPC, we have equivalent tables in the AsmParser and we should eliminate them in both places.
>
> Hum.  Curious.  I don't feel so bad about generating them then in the RegisterInfo area, as it is just RegisterInfo.
>
>> I recommend only generating (or including) the tables upon request.
>
> Done.  I did this in a way so that a first time port creator can easily discover the data in the .inc file, and if they want it, it then is obvious how to get it.
>
> I did a quick look through all the ports, and most can benefit from the tables if they want, as most ports have them.
>
> Ok?

Hi Mike, I think tablegenning these tables would be a great idea - I
too was recently caught out, getting garbage disassembly because I was
indexing into the register class rather than a decoder table. Your
patch seems sensible, though someone with more tablegen experience can
give a more thorough review. even the backends where you can get away
with relying on the order of registers in the regclass (e.g. XCore),
probably shouldn't.

See http://llvm.org/docs/DeveloperPolicy.html#making-and-submitting-a-patch
for guidelines on submitting a patch for inclusion. It's not a
requirement, but submitting to phabricator can help to get reviewers
(see http://llvm.org/docs/Phabricator.html for guidance). Fee free to
add me as a reviewer (asb). It looks like Hal (hfinkel) has
volunteered(!) and you could also add the TableGen code owner
(stoklund). Having a test case would also help - there's relatively
little testing of the C++ that tablegen generates, but you might look
at test/TableGen/AsmVariant.td for an example.

Once we have generated decoder tables, the common case by far will
involve the exact same implementation of DecodeFooRegisterClass, which
perhaps suggests there's an opportunity to delete more code by relying
on a default or generated implementation unless it needs to be
overridden (e.g. SPARC DecodeIntPairRegisterClass).

Best,

Alex