[PATCH] D148109: [mlir] Add a generic mem2reg implementation.
Jakub Kuderski via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 27 10:56:42 PDT 2023
kuhar added inline comments.
================
Comment at: mlir/lib/Transforms/Mem2Reg.cpp:245-246
+ for (OpOperand *blockingUse : newBlockingUses) {
+ assert(llvm::find(user->getResults(), blockingUse->get()) !=
+ user->result_end());
+
----------------
nit: Use `llvm::is_contained`
================
Comment at: mlir/lib/Transforms/Mem2Reg.cpp:188
+
+ assert(isResultOrNewBlockArgument &&
+ "a slot must be a result of the allocator or an argument of the "
----------------
gysit wrote:
> kuhar wrote:
> > gysit wrote:
> > > This may trigger a warning if compiled without assertion. The standard way to avoid this is putting
> > >
> > > ```
> > > (void)isResultOrNewBlockArgument;
> > > ```
> > > before the assertion. Also consider starting the search from the slot.ptr and then call get defining op / cast it to a block argument, e.g:
> > > ```
> > > auto isResultOrBlockArgument = [&](Value value) {
> > > if (value.getDefiningOp() == allocator)
> > > return true;
> > > if (BlockArgument arg = value.dyn_cast<BlockArgument>())
> > > if (arg.getOwner()->getParentOp() == allocator)
> > > return true;
> > > return false;
> > > }
> > > ```
> > >
> > In this specific case, shouldn't the whole body of this constructor be guarded by `#ifndef NDEBUG`?
> >
> > IE this block does not produce any results/side-effects used in non-debug builds.
> Yes that sounds right. Without NDEBUG there is probably an unused variable warning as well.
This hasn't been fully addressed
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D148109/new/
https://reviews.llvm.org/D148109
More information about the llvm-commits
mailing list