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.his a generated header. I thought this might be a part ofCore. It was pragmatic but less reasonable. - Should be available in TableGen. If this is a part of
CodeGen(before D148769),llvm-tblgenwould depend on too many components (includes Transforms) even if most of them were pruned by--gc-sections. - Both
LLT.handMVT.hare used inCodeGenand its dependents. I thinkCodeGenmay be the right place theoretically (but inefficiently and not practically). It would not make sense ifCodeGenTypeswere a part ofCore(or remained as a part ofSupport)
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.