Include all of the store's source vector operands when creating the MachineMemOperand. Previously, we were missing the first operand, making the store size seem smaller than it really is.
Details
- Reviewers
niravd trong sdesmalen jfb eli.friedman mstorsjo t.p.northover javed.absar - Commits
- rG3e89fa8e088d: [AArch64] Create proper memoperand for multi-vector stores
rG53e869da7d66: [AArch64] Create proper memoperand for multi-vector stores
rL345631: [AArch64] Create proper memoperand for multi-vector stores
rL345315: [AArch64] Create proper memoperand for multi-vector stores
Diff Detail
- Repository
- rL LLVM
Event Timeline
I don't have a good testcase for this, unfortunately. I discovered it while investigating strange aliasing results on a very large code. I'm not entirely sure how to write a synthetic test for machine-level alias analysis. I can write the IR of course but I don't know how to run alias analysis on it and spit out useful information to compare with FileCheck. The alias analysis has to happen after isel. Is anyone aware of other tests that do something like that?
I don't have a complete solution for you, but for trying to come up with smaller cases when compiling larger code bases, I've had a lot of success and am a big fan of creduce. Also, it might be interesting to see if the original author of this line left context for _why_ this loop starts at 1 rather than 0 in their commit message. With a git checkout, you can find the commit that last touched this (which isn't necessarily the commit that added it) via git blame <file> -L <line number>. Then with that sha of the commit, git show <sha>. Might have more information.
You could just directly test that the computed memory operand is correct: write a test that runs "llc -stop-after=isel" and check the MIR. Without your patch, you should see something like "ST1Fourv2d killed %5, %4 :: (store 48 into %ir.addr, align 64)"; with your patch, that will be "store 64".
I don't think it's necessary to write a test where the final assembly is actually affected by the incorrect memory operand.
I checked that but didn't find anything enlightening. My guess is that at one time the intrinsics were defined to take the address as the first operand but then later got switched to make the address the last operand.
test/CodeGen/AArch64/multi-vector-store-size.ll | ||
---|---|---|
69 ↗ | (On Diff #168430) | I'm pretty sure these numbers aren't right. You don't have to fix it here, necessarily; being overconservative isn't really a big deal. But it would be nice to have a note in the testcase. |
test/CodeGen/AArch64/multi-vector-store-size.ll | ||
---|---|---|
69 ↗ | (On Diff #168430) | Yeah, there's an explicit comment in the lowering code about being conservative. I'll add a similar comment to the test. |
LGTM modulo minor typo .
test/CodeGen/AArch64/multi-vector-store-size.ll | ||
---|---|---|
73 ↗ | (On Diff #170405) | entire* |