Layering-wise, it seems RegisterBank stuff fits under CodeGen, like
other target abstraction.
In particular, TargetSubtargetInfo has a getRegBankInfo member, but
using that object requires making sure GlobalISel is linked, which is
not always the case (e.g. llvm-jitlink doesn't).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
If this change is actually OK/desirable, I can move the .h files over, too, and fix-up the includes. There are ~20 or so occurrences, so maybe I can do that in a subsequent patch (probably also see which are used, too)
Just want to double check: You have a (possibly downstream) use case that wants to leverage RegisterBank without linking GlobalISel, is that correct?
My two-cent is that since none of the upstream code uses RegisterBank outside GlobalISel context, I don't see much justification on making this change. That said, if this situation changes in the upstream in the future (i.e. some other components also use RegisterBank) moving to CodeGen might be a way.
Yes, a subsequent change would do that: add bank-ness info as a feature to the ML eviction advisor.
My two-cent is that since none of the upstream code uses RegisterBank outside GlobalISel context, I don't see much justification on making this change. That said, if this situation changes in the upstream in the future (i.e. some other components also use RegisterBank) moving to CodeGen might be a way.
It could help others, too, hence wanted to introduce this "for its own merit" - i.e. the justification being cleanup (architectural, in this case).