This patch adds canonicalization conditions for omp.atomic.update thus
eliminating it when it becomes just a write or a no-op due to other
changes during canonicalization.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks @shraiysh for this patch.
"This patch adds canonicalization conditions for omp.atomic.update thus
eliminating it when it becomes just a write or a no-op due to other
changes during canonicalization."
Could you expand this a bit more? Is it write with the same value?
Could you also check whether it is OK to accept atomic updates like the following?
func.func @update_unnecessary_computations(%arg0: memref<i32>) { %c0_i32 = arith.constant 0 : i32 omp.atomic.update %arg0 : memref<i32> { ^bb0(%arg1: i32): %0 = arith.cmpi ne, %arg1, %c0_i32 : i32 %1 = arith.extui %0 : i1 to i32 %2 = arith.addi %arg1, %1 : i32 omp.yield(%2 : i32) } return }
This will work as expected - there will be an atomic update to the location with the new value (lowering to LLVM IR will also work as expected). However, I understand that we might not be able to reach this situation because C/C++/Fortran semantic checks will stop it.
mlir/test/Dialect/OpenMP/canonicalize.mlir | ||
---|---|---|
17–23 |
@kiranchandramohan here is an example where an atomic update operation is essentially an atomic write operation. Due to other simplifications during canonicalization of the ops under atomic update region (possibly unrelated to the openmp dialect) like elimination unused instructions etc. - if the IR reaches this state after after them, then this will be replaced with an atomic write operation writing the same value (as can be seen in CHECK lines under this) to the memory. |
Ping for review. (This is not urgent for the drop on July 26th, and patches related to those are high priority. This is just a gentle reminder, if anyone is willing to look into this patch. :) )
mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp | ||
---|---|---|
841 | No, removed the check from here. It is already there in the verifier. |
Is there a case for AtomicUpdateOp where yieldOp can have more or less than 1 operand?