This is an archive of the discontinued LLVM Phabricator instance.

[mlir][interfaces] Return destination OpOperands instead of Values
AbandonedPublic

Authored by springerm on Sep 1 2022, 7:29 AM.

Details

Summary

There are now two methods for retrieving destinations: getDestinationOpOperands and getDestination. The former one returns the OpOperands of the op. The latter one is allowed to create new IR in case the op does not have destination operands.

This change is in preparation of explicitly capturing shared tensors in scf.foreach_thread. Inside of the foreach_thread body, all destinations must be expressed in terms of the block arguments of the foreach_thread body.

Note: getDestinationOpOperands is identical to DestinationStyleOpInterface::getOutputOperands, but we cannot use DestinationStyleOpInterface yet because it was not yet moved to mlir/Interfaces.

Diff Detail

Event Timeline

springerm created this revision.Sep 1 2022, 7:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 7:29 AM
springerm requested review of this revision.Sep 1 2022, 7:29 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 7:29 AM
mravishankar requested changes to this revision.Sep 1 2022, 9:09 AM

I am not sure this change composes well. Specifically, there is no way an transformation can know if it is supposed to use getDestinationOperands or getDestinationOpOperands. I think eventually even getDestinationOperands needs to be dropped from the TilingInterface.

This revision now requires changes to proceed.Sep 1 2022, 9:09 AM

Specifically, there is no way an transformation can know if it is supposed to use getDestinationOperands or getDestinationOpOperands.

A transformation should use getDestinationOperands (now called getDestination). getDestinationOpOperands should be called only if it is important to know which OpOperand is the destination.

I think eventually even getDestinationOperands needs to be dropped from the TilingInterface.

There is a new op interface that was added recently: DestinationStyleOpInterface. This interface would be sufficient for my needs and I think can proceed with that interface instead. (So I can probably abandon this change.)

I'm wondering if DestinationStyleOpInterface could also be a full replacement for getDestinationOperands/getDestinationOpOperands. The main problem is that getDestinationOperands takes an OpBuilder and creates a tensor if there is no destination operand (e.g., tensor.pad). Do we create the exact same IR for every op without a destination (i.e., reify result shape + linalg.init_tensor)? In that case, we can indeed drop getDestinationOperands. I'll see if that works (as a further cleanup of the TilingInterface), but let me know if you see any issues with that approach.

springerm abandoned this revision.Sep 2 2022, 2:30 AM

You are probably right that reify result shape + init Tensor is probably what you will be needed. But that would add dependence of scf to Linalg.

@springerm I actually did find the use for this. Do you want to land this while you explore the other path... Might be less churn if you dont change the name of the method. So keep getDestinationOperands instead of renaming to getDestination?