I’ve thought the opposite of having multiple tablegen tools, but have one tablegen invocation perform all of the generators at once and in parallel. There’s a lot of time spent in common building target information paths, only some of which gets used depending in the output type.
Also there’s probably low hanging fruit to speed up GlobalISelEmitter. I’ve never looked at the profile for it.
In 2021, I took an option to plugin-ize tblgen, since I wanted to avoid intrusive changes in the tree. Then I didn’t think I could add other tblgen executables.
As I read comments, I think it would be yet another option to add specific tblgen(s), if it would be acceptable.
Although decoupling GISelEmitter would be effective, I think introducing “CodeGen’s tblgen” would be better. I will work if I have my time.
@jrtc27 I have looked around llvm-tblgen and MVT.
I expected CodeGen stuff could be split out easily, but I knew also intrinsics_gen depends on MVT.
Could we use ValueTypes.td directly from other td(s) to avoid using MachineValueType.h, at least for IntrinsicsEmitter?
I guess it would not be easy to rewrite all emitters since we would have to rewrite many emitters.
For now, I suspend considering ValueTypes.td.
@tschuett@nhaehnle Let me know why you don’t prefer plugin.
(As I said before, it should be an option)
@tstellar tblgen executables would be expected smaller.
With a few libraries to link each tblgen executable.
If we would build plugins, each plugin module would be a few object files with a few dynamic libraries.
I think it would not be a problem unless we would try linking hundred of tblgen(s).
to answer this specific question, I think anyone is eligible. Usually we look into the commit history (of the files you changed) and tag people who are most relevant as the reviewers. Though not always, you can also tag the code owner.
chapuni has been associated with LLVM for a long time, so I think he understands who’s eligible. But his native language is Japanese. I think the real question is, who would be an appropriate reviewer.
Actually - we ran into this issue last year… Clang-tools-extra ended up with 2 new build-time executables, which needed similar variables for pointing out such a preexisting binary; we added similar cmake variables for pointing out those executables.
I know many tests in test/TableGen should be updated to use llvm-cg-tblgen. I will propose patches in this weekend.
This is the top of test-depends. The gap has been reduced so much, 20s to 9s. It is a big win on manycore machines. You can see that CodeGen emitters (including GISelEmitter) are independent from intrinsics_gen.