================
@@ -32,6 +33,68 @@ namespace mlir {
namespace {
+/// Find the `cir.store` operation that stores to the given alloca and
dominates
+/// the given load operation. Dominance calculation is done through the given
+/// DominanceInfo object.
+///
+/// Return nullptr if no such store operation exists. If multiple store
+/// operations satisfy the criteria, any of them may be returned.
+cir::StoreOp findDominatingInitOp(cir::AllocaOp alloca, cir::LoadOp load,
+ const DominanceInfo &domInfo) {
+ // Walk through all uses of the alloca and visit the store operations that
+ // store to the alloca
+ for (const mlir::OpOperand &use : alloca->getUses()) {
+ auto store = mlir::dyn_cast<cir::StoreOp>(use.getOwner());
+ if (!store)
+ continue;
+
+ // `cir.store` has two operands, we're only interested if the store is
+ // storing into the alloca, not if the store is storing the address of the
+ // alloca slot into somewhere else
+ if (use.getOperandNumber() != cir::StoreOp::odsIndex_addr)
----------------
Lancern wrote:
> this seems a little bit of an awkward way of checking this?
I don't know if there's a better way to check this, maybe we could make this a
member function of the `LoadOp` class `isStoringInto` that checks whether the
store operation is storing into some address?
> do we care if THIS is an atomic or volatile store?
This is a very good point. I feel that it's OK to fold the load away if the
corresponding store is atomic/volatile, but I would definitely also agree that
we could ask some C/C++ language expert for this. Before that, maybe we could
be conservative and do not fold if the store is atomic/volatile?
https://github.com/llvm/llvm-project/pull/212284
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
