Here is my proposal for the same style of split, but for all targets, not just RISC-V: ⚙ D137838 [RFC][Support] Move TargetParsers to new component
This takes all of the Target Parsers, and puts them in the same, new component. The difficult parts are:
-
llvm/ADT/Triple.his moved into this component because it depends on the Arm target parsers. -
llvm/Support/Host.his moved into this component because it depends on the x86 target parser.
This would then allow more targets than just RISC-V to use tablegen in their target parsers.
This has several dependent patches:
-
⚙ D137837 [Support] Move Target/CPU Printing out of CommandLine - which moves the printing of the current process triple and cpu out of
llvm/Support/CommandLine, but tries to preserve the same output in most tools. I forsee this as being controversial. -
⚙ D137836 [Support] Move getHostNumPhysicalCores to Threading.h A cleanup to bring reasonable functions together.
-
⚙ D137835 [ARM] Move ARM::parseBranchProtection into ARMTargetParser A cleanup to the arm target parsers, to bring a function into the target-specific libraries.
-
⚙ D137834 [Support] Reduce Dependence on Host.h A cleanup to avoid using
llvm/Support/Host.hwhen the same logic is more clearly available fromllvm/Support/SwapByteOrder.h.
There are likely further cleanups I might do in future, given e.g. the x86 target parser has a copy of FeatureBitset from llvm/MC/SubtargetFeature.h. I think it might be better to have this data structure just live in llvm/TargetParser, maybe along with some of the other feature handling utility classes.
One thing I wasn’t sure about was whether we should be moving the target-specific Build Attribute handling code in Support into this component too. I think we can do that later if we choose to.
Comments welcome.