This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg] Support non-function ops in Detensorize
AcceptedPublic

Authored by springerm on Feb 9 2023, 7:58 AM.

Details

Summary

This fixes #58748.

Diff Detail

Event Timeline

springerm created this revision.Feb 9 2023, 7:58 AM
Herald added a project: Restricted Project. · View Herald Transcript
springerm requested review of this revision.Feb 9 2023, 7:58 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 9 2023, 7:58 AM
hanchung accepted this revision.Feb 9 2023, 3:25 PM
This revision is now accepted and ready to land.Feb 9 2023, 3:25 PM
mravishankar requested changes to this revision.Feb 9 2023, 3:32 PM

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 .

This revision now requires changes to proceed.Feb 9 2023, 3:32 PM

address comments

This revision is now accepted and ready to land.Feb 16 2023, 9:56 PM

Why is this tied to the concept of a function? Why wouldn't any isolated op work equivalently here?

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.

Where is the type change happening for entry block? I missed it I think

Where is the type change happening for entry block? I missed it I think

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...

springerm retitled this revision from [mlir][linalg] Make LinalgDetensorize a function pass to [mlir][linalg] Support non-function ops in Detensorize.Feb 22 2023, 8:28 AM

Where is the type change happening for entry block? I missed it I think

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>()):

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 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.