[PATCH] D88385: [TableGen][M68K] (Patch 1/8) Utilities for complex instruction addressing modes: CodeBeads and logical operand helper functions

[Min-Yih Hsu via Phabricator via llvm-commits]

myhsu added a comment.

In D88385#2476167 <https://reviews.llvm.org/D88385#2476167>, @RKSimon wrote:

> Do you have any idea how much work would be necessary for the TSFlags refactor?

I think it is pretty straight forward to switch our MC code to use `MCInstrDesc::TSFlags` -- if we managed to rewrite our TG files to use `TSFlags`, which is a bigger problem. Adapting our TG code to use `TSFlags` requires modifying most the instruction definitions, as far as I can say.

In D88385#2476220 <https://reviews.llvm.org/D88385#2476220>, @Paul-C-Anagnostopoulos wrote:

> If it isn't possible to encode the information in TSFlags, another possibility is to add a pointer to the MCInstrDesc class that points to some kind of auxiliary class/struct.

This actually gives me an idea to directly use the `MCInstrDesc::TSFlags` as a //pointer// to auxiliary data structures. That is:

  auto* AuxTable =  reinterpret_cast<uint8_t*>(MD.TSFlags);

That means we also need to modify InstrInfoEmitter. Here is my preliminary plan:

1. In the `Instruction` TG class, add a new string field, `ExtTSFlagsFieldName`. That's say the value of this field is set to "foo"
2. If `TSFlags` in `Instruction` TG class is 0xFF...FF, `InstrInfoEmitter` will lookup field "foo". This "foo" field needs to be a `bits`, but the size need not to be 64 bits.
3. Following up step 2, `InstrInfoEmitter` construct auxiliary data structures according to the value of "foo" field.
4. Assign pointer to auxiliary data structure as the value of `MCInstrDesc::TSFlags`.

The reason there is an indirection on step 1 and 2 (i.e. use `ExtTSFalgsFieldName` to lookup auxiliary data's field name) is because TG's `bits` type can only have fixed size but we want downstream users to specify the size of their auxiliary data structure.

Biggest advantage of this approach is that we barely need to modify our TG code.

I'm definitely not a TG expert, so @Paul-C-Anagnostopoulos please speak out if you have any suggestion on this approach :-)


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88385/new/

https://reviews.llvm.org/D88385