This fixes #58748.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I see why you made it a function pass, but I think it needs to be a pass on FunctionOpInterface. There are examples of this in IREE https://github.com/iree-org/iree/blob/55d0ffe7ea4ca5b58dd9197608151cc2f8c7521c/compiler/src/iree/compiler/Dialect/Flow/Transforms/Passes.td#L65 .
Why is this tied to the concept of a function? Why wouldn't any isolated op work equivalently here?
Maybe. I'm not sure. Some IsolatedFromAbove ops expose operands as block arguments. Changing the type of these block arugments could make the op invalid. There are extra checks in this pass to exclude the bbargs of the first block of a function.
There's a comment in line 496:
// A function is legal if all of its non-entry blocks are legal. We // don't legalize the entry block (i.e. the function's signature) // since detensoring can't happen along external calling convention // boundaries, which we conservatively approximate as all function // signatures.
It may be possible to wrap this part in AggressiveDetensoringModel::compute etc in a if (auto funcOp = dyn_cast<FunctionOpInterface>()):
for (Block &block : llvm::drop_begin(func.getFunctionBody(), 1))
for (BlockArgument blockArgument : block.getArguments())
blockArgsToDetensor.insert(blockArgument);It's the first time I'm seeing this transformation so I'm a bit reluctant to make larger changes...
I don’t follow, isn’t the comment saying that this won’t touch the entry block?
I don’t quite get why any change would be needed, seems like we’re reading this the opposite way.
I don’t follow, isn’t the comment saying that this won’t touch the entry block?
correct, I'm wondering if it is safe to do the same for other ops (non function). or if we should not touch these at all.
I don't why why it wouldn't be safe?
That was the point of my comment actually, there is nothing special to "FunctionInterface" here as far as I can tell.