[llvm-dev] generated HWEncoding based register decoders

[Hal Finkel via llvm-dev]

On 02/14/2017 10:16 AM, Alex Bradbury wrote:
> 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).

Mike, are you interested in follow-up on this? It would indeed be easier 
to go the code review using reviews.llvm.org (our phabricator 
code-review system). I'd really like to have this functionality, but we 
should talk about the details. We probably want to collect the values in 
a map, for example, instead of having the N^2 loop.

Thanks again,
Hal

>   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

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory