[PATCH] D33056: [NewGVN] When a store becomes the leader, update the memory leader for the class

Daniel Berlin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed May 10 12:50:38 PDT 2017


dberlin added a comment.

In https://reviews.llvm.org/D33056#751369, @davide wrote:

> I think we might just be missing a check for store count (as it's done in the other place we call `getNextMemoryLeader()`).
>  Please let me know what you think, and thanks for catching the mistake!
>
>   diff --git a/lib/Transforms/Scalar/NewGVN.cpp b/lib/Transforms/Scalar/NewGVN.cpp
>   index 3c9850b..f7182f2 100644
>   --- a/lib/Transforms/Scalar/NewGVN.cpp
>   +++ b/lib/Transforms/Scalar/NewGVN.cpp
>   @@ -1381,7 +1381,7 @@ bool NewGVN::setMemoryClass(const MemoryAccess *From,
>            NewClass->memory_insert(MP);
>            // This may have killed the class if it had no non-memory members
>            if (OldClass->getMemoryLeader() == From) {
>   -          if (OldClass->memory_empty()) {
>   +          if (OldClass->memory_empty() && OldClass->getStoreCount() == 0) {
>                OldClass->setMemoryLeader(nullptr);
>              } else {
>                OldClass->setMemoryLeader(getNextMemoryLeader(OldClass));
>  
>   fluttershy at SONY-PC C:\Users\fluttershy\work\llvm
>


Oh, yes, I believe you have discovered the root cause.
Sigh.
I really wish it was easy to unify all this handling into one place.

Can you add a definesNoMemory or something to CongruenceClass, and use it here?
It should be memory_empty && storecount == 0

Then we can also replace this check:

  if (OldClass->getStoreCount() != 0 || !OldClass->memory_empty()) {

with it

(This will also force us to make sure the class is in a consistent state. It would also let us add an assert that  that if (CC->definesNoMemory()), then <nothing in ->members() is a store> && and memory_empty()) in a few places.
(though this is an expensive assert)


https://reviews.llvm.org/D33056





More information about the llvm-commits mailing list