Details
Diff Detail
Event Timeline
This will LGTM for the architectures supported by GlobalISel at the moment with a couple more tests but I think there's targets in LLVM that need different behaviour (PowerPC?). If that's the case, should we account for this now or later?
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | This looks correct for ARM/AArch64/Mips, but I'm not sure this is correct for all targets. I'm thinking of big-endian targets where the highest-numbered element is stored at bit 0 (PowerPC?). | |
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
1237–1245 | I'd add a couple more tests, one for another vector size (preferably not a power of 2) and one for a different type and size like 'double'. |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | If this is not correct for some targets, there should at list be a FIXME here explaining in what circumstances the code isn't correct? | |
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
1237–1245 | My guess is that non-power-of-2 vector sizes are too ill-supported to be able to write tests using them at the moment? |
I'm not sure we want to use G_SEQUENCE for this. It seems to me that we should figure out a representation for vectors in general before diving into constants.
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | This isn't always a valid assumption; we can have things like v16i1. Make this size in bits instead? |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 |
v16i1 can't occur here. ConstantDataVector handles the common case vectors where the elements are i8/i16/i32/i64/half/float/double. The v16i1 case is handled by ConstantVector instead. |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | A genuine question, does SD care about the endian distinction for building vectors? | |
1024 | For this case we should use G_MERGE. | |
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
1237–1245 | For the IRTranslator non-power-of-2 vectors should be fine. |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | I don't think it matters to the SelectionDAG representation but I believe it's important to the transition between SelectionDAG nodes to MachineInstrs. Mips was handling the bitconvert differences at instruction selection time. I'm not familiar with the PowerPC instruction set but it looks like PowerPC is doing some endian aware lowering of BUILD_VECTOR in PPCTargetLowering::LowerBUILD_VECTOR(). I suppose the key question to answer is: Do gMIR's virtual registers hold SelectionDAG values or physical register values? |
lib/CodeGen/GlobalISel/IRTranslator.cpp | ||
---|---|---|
1022 | SelectionDAG uses the same order to build vector. |
LGTM + test case
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
---|---|---|
1237–1245 | Could you add a non-power-of-2 test case? |
This approach makes sense to me too, thanks folks! If no one else has a paragraph handy, I'll try to explain the whole post-G_SEQUENCE scheme in the docs page.
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
---|---|---|
1264–1272 | Any reason for this test to involve an extractelement? |
test/CodeGen/AArch64/GlobalISel/arm64-irtranslator.ll | ||
---|---|---|
1264–1272 | We are unable to translate ret <3 x i32> <...>, so I tried something else. |
This isn't always a valid assumption; we can have things like v16i1.
Make this size in bits instead?