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

[Renato Golin via Phabricator via llvm-commits]

rengolin added a comment.

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

> Why would refactoring TSFlags into a int-ptr union just for M68k be better than adding the CodeBeads functionality just for M68k?

I think the question is more of a "where does this belong" than "why are we doing this".

If we want to auto-generate tables at compile time, then table-gen is your friend. If this should be a bit more dynamic, then working around auto-generated tables can be cumbersome and counter productive.

The other question is "when should we do this".

We already have an implementation (CodeBeads) which I'm assuming came from an existing implementation, so (still assuming) we "know it works with m68k". The table-gen approach is so far an idea that "could" work. Working with table-gen is non-trivial.

In interest of doing one thing at a time, I'd prefer to keep the existing implementation for now and do a refactor later. As I see it, the refactor should only affect the m68k back-end.

In summary, my personal view is:

- We have something that works now and the proposed alternative is equally unique
- We should answer the "where" question before we go on implementing a new style
- If it's decided a table-gen implementation fits better, we do it as a refactory, after the merge

Putting a bit TODO comment on the current CodeBeads code will help others not try to rely on it in the interim. But if they do, then this would have proven it's more than just m68k.


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

https://reviews.llvm.org/D88385