This is the final chunk of my original legalizer outline (well, there were a couple more transformations originally, but they're trivial from a review perspective). It adds a helper class to actually perform legalization, and a pass that currently iterates through a MachineFunction applying it to each instruction. Just one transformation is implemented for now.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Hi Tim,
LGTM modulo the name of the extract/sequence things. I don’t think it is a good idea to be close to the subreg world at this point.
See comment inlined.
Cheers,
-Quentin
include/llvm/CodeGen/GlobalISel/MachineIRBuilder.h | ||
---|---|---|
155 | I would prefer we stick to extract, extract subreg is highly correlated with sub registers, which is not what we do here. If you have idea for a different name that would work as well :). Anyhow, open to suggestion but not g_extract_subregs, it is too close to extract_subreg while being too different. | |
158 | In my mind the size was not necessarily the same for all extracted operands. | |
166 | Ditto, stick with G_SEQUENCE, or G_BUILD_SEQUENCE. | |
172 | Add a pre condition that the sum of the size of the arguments must be equal to the size of the \p Ty. | |
include/llvm/Target/GenericOpcodes.td | ||
49 | G_EXTRACT. | |
57 | G_SEQUENCE. | |
lib/CodeGen/GlobalISel/MachineLegalizePass.cpp | ||
28 | Use DEBUG_TYPE | |
49 | This may impact the APIs, so maybe we should settle that now. | |
lib/CodeGen/LLVMTargetMachine.cpp | ||
170 | if … | |
test/CodeGen/AArch64/GlobalISel/legalize-add.mir | ||
23 | This one shouldn’t use DAG |
Thanks Quentin! Committed with the suggested changes as r276461.
include/llvm/CodeGen/GlobalISel/MachineIRBuilder.h | ||
---|---|---|
158 | Working on it (just whacking a SmallVector into the MachineInstr)! But I'll upgrade G_EXTRACT afterwards. | |
lib/CodeGen/GlobalISel/MachineLegalizePass.cpp | ||
49 | Soon, but adding enough to test a multi-step legalization would bloat this patch. |
I would prefer we stick to extract, extract subreg is highly correlated with sub registers, which is not what we do here.
If you have idea for a different name that would work as well :).
When I come up with the name I had "bitfield extract” in mind. But with can think that as a pack as well or a scatter. Pack/unpack for build_sequence/extract may be good because it shows up the symmetry between the two.
Anyhow, open to suggestion but not g_extract_subregs, it is too close to extract_subreg while being too different.