This is an archive of the discontinued LLVM Phabricator instance.

[EarlyCSE] Handle calls with no MemorySSA info.
ClosedPublic

Authored by gberry on Jul 12 2017, 11:45 AM.

Details

Summary

When checking for memory dependencies between calls using MemorySSA,
handle cases where the calls have no MemoryAccess associated with them
because the AA analysis being used has determined that the call does not
read/write memory.

Fixes PR33756

Diff Detail

Repository
rL LLVM

Event Timeline

gberry created this revision.Jul 12 2017, 11:45 AM
Ka-Ka added a subscriber: Ka-Ka.Jul 13 2017, 12:35 AM
vsk added a subscriber: vsk.Jul 13 2017, 6:59 PM
dberlin edited edge metadata.Jul 14 2017, 12:15 AM

You may want to not treat these as memory at all, as Vedant suggested on list.

As a further example of the advantages of that approach, i believe
" if ((Inst->mayReadFromMemory() || Inst->mayThrow()) &&

  !(MemInst.isValid() && !MemInst.mayReadFromMemory()))
LastStore = nullptr;"

Will still trigger in your current fix for these calls, but should not.

In fact, it can't read from memory if it has no memory access.

IE you should be able to have a testcase where your current fix avoids eliminating a store, but changing this routine to say "if memoryssa doesn't think it has an access, and it doesn't throw, it's fine", does eliminate the store.

lib/Transforms/Scalar/EarlyCSE.cpp
567 ↗(On Diff #106266)

you can auto * these

davide edited edge metadata.Jul 14 2017, 8:31 AM

This fix is basically correct, I'm fine with this going in after Dan's comments are addressed.
I don't have strong opinions on the alternative solution suggested by Vedant, so up to you.

test/Transforms/EarlyCSE/globalsaa-memoryssa.ll
13–18 ↗(On Diff #106266)

Consider autogenerating checks using the update-test-checks.py in llvm/utils

Yeah, i forgot to say, i'm fine if you just want to fix this as you have already, but if you do, you should leave a note saying it's not optimal or something.

I'm going to go ahead with this version of the fix (with the comments addressed). I implemented the stronger version (i.e. looking at MSSA memory accesses when checking doesNotAccessMemory, onlyReadsMemory, mayReadFromMemory, mayWriteMemory) and saw a total of 2 differences in the values returned from these checks across all of our benchmarks, and no change in code generation at all. Given the amount of code churn to implement this and how close we are to release, I'm going to take the conservative route.

I'm going to go ahead with this version of the fix (with the comments addressed). I implemented the stronger version (i.e. looking at MSSA memory accesses when checking doesNotAccessMemory, onlyReadsMemory, mayReadFromMemory, mayWriteMemory) and saw a total of 2 differences in the values returned from these checks across all of our benchmarks, and no change in code generation at all. Given the amount of code churn to implement this and how close we are to release, I'm going to take the conservative route.

Fair enough, Geoff.

This revision was automatically updated to reflect the committed changes.