This is an archive of the discontinued LLVM Phabricator instance.

[AArch64] Create proper memoperand for multi-vector stores
ClosedPublic

Authored by greened on Oct 2 2018, 6:20 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

greened created this revision.Oct 2 2018, 6:20 PM

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.

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".

Ah yeah, that's a great idea. I'll do that. Thanks!

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.

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.

greened updated this revision to Diff 168430.Oct 4 2018, 7:24 PM

Added testcase.

efriedma added inline comments.Oct 5 2018, 11:21 AM
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.

greened added inline comments.Oct 8 2018, 6:11 PM
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.

greened updated this revision to Diff 170405.Oct 22 2018, 6:58 AM

Added comments about conservative store sizes.

greened marked an inline comment as done.Oct 22 2018, 6:58 AM
niravd accepted this revision.Oct 22 2018, 7:21 AM

LGTM modulo minor typo .

test/CodeGen/AArch64/multi-vector-store-size.ll
73 ↗(On Diff #170405)

entire*

This revision is now accepted and ready to land.Oct 22 2018, 7:21 AM
This revision was automatically updated to reflect the committed changes.