Page MenuHomePhabricator

[mlir][linalg] Add support for scalar input operands.

Authored by gysit on Jun 11 2021, 4:47 AM.



Up to now all structured op operands are assumed to be shaped. The patch relaxes this assumption and allows scalar input operands. In contrast to shaped operands scalar operands are not indexed and directly forwarded to the body of the operation. As all other operands, scalar operands are associated to an indexing map that in case of a scalar or a 0D-operand has an empty range.

We will use scalar operands as a replacement for the capture mechanism. In contrast to captures, the approach ensures we can generate the function signature from the operand list and it prevents outdated capture values in case a transformation updates only the capture operand but not the hidden body of a named operation.

Removing captures and updating existing operations such as linalg.fill is left for a later patch.

The patch depends on and

Diff Detail

Event Timeline

gysit created this revision.Jun 11 2021, 4:47 AM
gysit requested review of this revision.Jun 11 2021, 4:47 AM
nicolasvasilache accepted this revision.Jun 11 2021, 5:11 AM

Very nice!

This revision is now accepted and ready to land.Jun 11 2021, 5:11 AM

I wouldn't shay away form changing the pretty form (in a followup CL as it will involve a bunch of updates).

I'd either go for linalg.fill %t with %v : tensor<..xf32> with f32 (which is more idiomatic) or linalg.fill %v into %t : f32 into tensor<..xf32> (which is consistent re. operand order).

This revision was landed with ongoing or failed builds.Jun 13 2021, 11:28 PM
This revision was automatically updated to reflect the committed changes.
aartbik added inline comments.Jun 14 2021, 3:51 PM

Is this enforced, or should this just bail the rewrite?

gysit added inline comments.Jun 14 2021, 11:08 PM

At the moment, there are no linalg operations with scalar operands and I added the assertion rather as a bail out. However, I plan to soon switch linalg.fill from captures to a scalar parameters but I don't think that affects the sparse compiler directly. If it is possible to support scalar parameters with relatively little effort I would go ahead and remove the assertion. I was just not sure how to do it the right way.