Update effects for acquire and release operations (#8399)

One of the primary use cases of `EffectAnalyzer` is to determine whether
one expression (or a sequence of expressions) can be reordered before or
after another expression (or sequence of expressions). Until now, the
check whether effects "invalidate" each other and would prevent
reordering has been symmetrical, checking read-write, write-write, and
write-read conflicts as well as symmetric conditions that would prevent
reordering. But acquire load and release store operations break this
symmetry.

Consider an expression A containing an acquire load (and no other
effects) and an expression B containing a release store (and no other
effects), where we know the accesses do not alias. Then if A is before
B, it is not valid to reorder the expressions to have B before A because
the acquire load cannot move forward past the release store and the
release store cannot move back past the acquire load. However, if B is
before A, it _is_ valid to reorder them, since memory accesses are
generally allowed to move forward past acquire loads and back past
release stores.

Update `EffectAnalyzer` to take these allowed reorderings into account
by tracking the strictest memory orders used to read or write to shared
locations in the analyzed expressions.

Now that the effect comparison to see whether reordering is prevented is
no longer symmetric, rename it from `invalidates` to the more
descriptive `orderedBefore`, where `A.orderedBefore(B)` returns true iff
`A` ocurring before `B` implies that there is an ordering constraint
that would prevent reordering `A` and `B` past each other. To accomodate
users trying to move expressions in either direction, also add an
`A.orderedAfter(B)` method for the case where `A` occurs after `B`.

To avoid having to update all users at once, keep an `invalidates`
method that checks for ordering in either direction. This maintains the
symmetry many users depend on. For now, update only SimplifyLocals to
use the more precise directional methods. Add tests both for all the
interesting combinations of atomic effect ordering and for the correct
use of directionality in SimplifyLocals.

Author: tlively

src/ir/effects.cpp

@@ -45,6 +45,12 @@ std::ostream& operator<<(std::ostream& o, wasm::EffectAnalyzer& effects) {
   if (effects.writesMemory) {
     o << "writesMemory\n";
   }
+  if (effects.readsSharedMemory) {
+    o << "readsSharedMemory\n";
+  }
+  if (effects.writesSharedMemory) {
+    o << "writesSharedMemory\n";
+  }
   if (effects.readsTable) {
     o << "readsTable\n";
   }
@@ -57,20 +63,35 @@ std::ostream& operator<<(std::ostream& o, wasm::EffectAnalyzer& effects) {
   if (effects.writesStruct) {
     o << "writesStruct\n";
   }
-  if (effects.readsArray) {
+  if (effects.readsSharedMutableStruct) {
+    o << "readsSharedMutableStruct\n";
+  }
+  if (effects.writesSharedStruct) {
+    o << "writesSharedStruct\n";
+  }
+  if (effects.readsMutableArray) {
     o << "readsArray\n";
   }
   if (effects.writesArray) {
     o << "writesArray\n";
   }
+  if (effects.readsSharedMutableArray) {
+    o << "readsSharedMutableArray\n";
+  }
+  if (effects.writesSharedArray) {
+    o << "writesSharedArray\n";
+  }
   if (effects.trap) {
     o << "trap\n";
   }
   if (effects.implicitTrap) {
     o << "implicitTrap\n";
   }
-  if (effects.isAtomic) {
-    o << "isAtomic\n";
+  if (effects.readOrder != wasm::MemoryOrder::Unordered) {
+    o << "readOrder " << effects.readOrder << "\n";
+  }
+  if (effects.writeOrder != wasm::MemoryOrder::Unordered) {
+    o << "writeOrder " << effects.writeOrder << "\n";
   }
   if (effects.throws_) {
     o << "throws_\n";