I have been working for TableGen and MachineValueType.h. I have confirmed that MVT can be generated from ValueTypes.td and MVT and LLT in llvm/Support can be restored to llvm/CodeGen.
Generate MVT from ValueTypes.td
- Implement
VTEmitter for MVT
- Let
IntrinsicEmitter independent from MVT
- Split
llvm-tblgen into “The minimal version llvm-min-tblgen just to emit llvm/include/llvm” and “The full version that depends on CodeGen headers”.
llvm-min-tblgen doesn’t depend on MVT anymore. In contrast, llvm-tblgen may use CodeGen headers (including generated headers by llvm-min-tblgen) without layering violations.
Restore MVT.h (and LLT.h) into llvm/CodeGen
With changes above, layering may be restructured. There would be no reason for MVT to stay in llvm/Support. Past changes are as below.
I am certain they could be restored.
Replace MVT.h with generated header
llvm-min-tblgen with VTEmitter can emit MVT.h. The full version llvm-tblgen can be built with generated headers. MVT.h may be replaced with generated one as far as it is equivalent to the static one.
Why “VTEmitter”?
Since it comes from ValueTypes.td. I don’t intend it would be only for MVT.
1 Like
I have proposed diffs for this.
-
MVT.h is generated from ValueTypes.td
-
llvm-tblgen can use MVT.h and LLT.h
https://reviews.llvm.org/D148770
My all diffs have been pushed.
Thanks @arsenm and @dblaikie for the reviews.
These are a few leftover issues as far as I know.
Feel free to open new topics for them.
Layout of CodeGenTypes
I have introduced LLVMCodeGenTypes as a sub component of LLVMCodeGen in ⚙ D148769 Split out `CodeGenTypes` from `CodeGen` for LLT/MVT. I wanted to isolate MVT.h from Support since I wanted to make MVT.h as a generated header.
I have got feedbacks from @dblaikie and @thakis.
My random thoughts for CodeGenTypes;
- Don’t remain a part of
Support. MVT.h is a generated header. I thought this might be a part of Core. It was pragmatic but less reasonable.
- Should be available in TableGen. If this is a part of
CodeGen (before D148769), llvm-tblgen would depend on too many components (includes Transforms) even if most of them were pruned by --gc-sections.
- Both
LLT.h and MVT.h are used in CodeGen and its dependents. I think CodeGen may be the right place theoretically (but inefficiently and not practically). It would not make sense if CodeGenTypes were a part of Core (or remained as a part of Support)
OTOH, I understand it is nasty for CodeGenTypes to be a sub component of CodeGen in the same directory with PARTIAL_SOURCES_INTENDED). I was too afraid if I made things more intrusive.
Could we move CodeGenTypes to elsewhere? So, could we move LLT.h and MVT.h as well? Could you suggest a better name than CodeGenTypes?
aarch64svcount
In ValueTypes.td, this is defined as a simple ValueType with bw=16 and no other attributes.
In MVT::getSizeInBits(), this should be treated as TypeSize::Scalable(16).
I committed a quick fix rGd091a19e58a2, or we saw TypeSize::Fixed(16)
LegalizeDAG.cpp:702: void {anonymous}::SelectionDAGLegalize::LegalizeLoadOps(llvm::SDNode*): Assertion `NVT.getSizeInBits() == VT.getSizeInBits() && "Can only promote loads to same size type"' failed.
I wonder how to handle this. I didn’t think good idea to define aarch64svcount as let isScalable=true in ValueTypes.td.
From ⚙ D148767 Restore CodeGen/LowLevelType from `Support`, @s-barannikov
I added deps pessimistically, “This depends on CodeGenTypes if LowLevelType.h is included”.
Sorry if I was not being clear. Dependencies are harmful and should be avoided wherever possible.
They should not be added “just in case”. Now when I want to build just llvm-mc I have to build half of the whole stack.
Although D148769 improves the situation, it does not justify adding these dependencies.
Your RFC was about dependencies, so I think you understand my concern.
Please try to remove them and only keep the ones that are really necessary.
I wrote thoughts above.
FYI, for example LLVMARMDesc, it has required LLT impl with Debug(non-optimized) before my changes.
1 Like