[Mlir-commits] [mlir] [MLIR][SideEffects][MemoryEffects] Modified LICM to be more aggressive when checking movability of ops with MemWrite effects (PR #155344)

Mehdi Amini llvmlistbot at llvm.org
Wed Dec 24 04:45:53 PST 2025


================
@@ -347,18 +347,39 @@ struct AlwaysSpeculatableImplTrait
 //===----------------------------------------------------------------------===//
 
 namespace MemoryEffects {
-/// Defines the priority of the different memory effects.
+/// Defines the expected evaluation priority/order of the different Memory
+/// Effects for when two Effect instances on the same op are defined with the
+/// same Stage.
 ///
-/// Sorting/ordering memory effects of an operation is done based on
-/// their defined stage and priority, in that order. If stage values for two
-/// effect instances are equal, they are then sorted by priority. Lower priority
-/// values indicate higher precedence.
+/// This adds a concrete evaluation priority to the Effect instances to allow us
+/// to analyze potential Memory Effect conflicts in a transparent, predictable,
+/// and deterministic manner AND creates a better defined contract with users.
+/// i.e., a set of Memory Effect instances on an op could look like the
+/// following: [MemRead<rA, 0>, MemFree<rA, 0>] where the evaluation order is
+/// ambiguous based on how the user defined both effects with the same Stage 0.
+/// If we Read then Free, we are safe. If we Free first, then we'll Read
+/// garbage. Reordering the effects based on priority removes this ambiguity.
+/// Stage values can be leveraged by users to define the exact order that the
+/// Effect instances take place.
+///
+/// When sorting an op's MemoryEffects, we first sort the effect instances
+/// in increasing Stage order. If Stage values for two Effect instances are
+/// equal, they are then sorted in order of decreasing priority, as defined
+/// by this enum. Higher priority values indicate higher precedence.
----------------
joker-eph wrote:

You cannot sort them: you need to consider these to be unordered and handle this conservatively.

https://github.com/llvm/llvm-project/pull/155344


More information about the Mlir-commits mailing list