[PATCH] D122832: [TableGen] Add a backend to help with target enums

[Fraser Cormack via Phabricator via llvm-commits]

frasercrmck added a comment.

Thanks for the input! Since it's not a clear "no" I've ploughed on.

One thing that probably needs a bit of feedback is whether this should continue to be a separate backend as I've got it in this patch. The searchable tables backend currently gathers `GenericEnum`s for use in tables //and// emits the decls, which I see as cross-purposes, but obviously another backend is adding extra compile time to targets. My inclination is to support `Enum` in the searchable tables backend but not emit them as enum decls anywhere but the enum backend. Then it's (arguably) cleaner that targets can choose the enum backend if they just want enums.

Also, if the searchable tables backend now uses `Enum` then `Enum` should live somewhere that `include/llvm/TableGen/SearchableTable.td` can include. So, `include/llvm/TableGen/Enum.td`?

Lastly, what's the deprecation/removal path for `GenericEnum` if this does go ahead? We only have one example of it in tree which is `AMDGPU`. I'm currently experimenting whether I can move everything there to `Enum`. I presume that this sort of TableGen infrastructure isn't part of a stable API, but I don't want to bother downstream targets if it can be helped. Apart from straight-up removal, one thought would be to drop `GenericEnum` enum generation but keep it for tables, and encourage people to move to `Enum`. Then remove it later?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122832