[PATCH] D138323: [TableGen] RegisterInfo backend - Add abstraction layer between code generation logic and syntax output

[Rot127 via Phabricator via llvm-commits]

Rot127 added a comment.

Thank you for the feedback!
Its my first time with LLVM so your critique is very valuable for me.

In D138323#4061704 <https://reviews.llvm.org/D138323#4061704>, @nhaehnle wrote:

> ... will users who want to extract information really want to extract all this information,

Please see the example with the `DecoderEmitter` below. In which case the answer would be yes.

> ... and if they do, will they want to do it in the same order and along the same hierarchy? What works for C++ might not work for another language and for another context.

Since the Printer controls the complete output, the hierarchy and order problem could be solved by it. Although it probably ends up in complicated printers.
So yes, non C like languages couldn't be printed in an elegant way.

> Ideally, you'd just use CodeGenTarget from a new printer, and potentially augment that class with additional features you may need.

I agree that this is the way to go for backends which emit mostly unprocessed information from the `CodeGenTarget`.
But it is complicated for backends like the `DecoderEmitter`.
This backend generates a state machine for decoding instructions and emits the C++ version of it. But the whole state machine generation logic is mixed together with the code printing.
So it is not possible to build a printer solely on top of the state-machine generation logic.

And maintaining an altered copy of it is maintenance heavy.

Would you say that in such a case this abstraction would be of use? Or should the state-machine generation be move to the `CodeGenTarget` in you opinion (as target-independent code generation algorithm I guess)?

My underling problem is that the `Emitter` backends don't just emit syntax. But quite often process (sometimes heavily) the information given by `CodeGenTarget` but don't make it accessible.

> The other meta problem here is that you're changing the code to be a lot less maintainable without an easily understandable in-tree motivation. For example: let's say we land this change. Soon after, anybody who looks at the code with these changes will immediately (and correctly) conclude that all those virtual methods aren't necessary and ought to be removed. Therefore, for out-of-tree purposes I would seriously urge you to just write a new printer that re-uses CodeGenTarget.

I could of cause add a Printer for C, but this is probably irrelevant as long as the other points are not solved.


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

https://reviews.llvm.org/D138323