This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Shape] Allow for `shape_of` to return extent tensors
ClosedPublic

Authored by frgossen on Jul 20 2020, 5:32 AM.

Details

Summary

The operation shape.shape_of now returns an extent tensor tensor<?xindex> in cases when no error are possible. All consuming operation will eventually accept both, shapes and extent tensors.

Depends On D84158

Diff Detail

Event Timeline

frgossen created this revision.Jul 20 2020, 5:32 AM
Herald added a reviewer: silvas. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
pifon2a accepted this revision.Jul 20 2020, 5:52 AM
pifon2a added inline comments.
mlir/lib/Dialect/Shape/IR/Shape.cpp
27

nit: move inline before RankedTensorType

herhut accepted this revision.Jul 20 2020, 6:02 AM

We should discuss whether we in the long run want to allow known-size tensors for known-rank inputs.

We should discuss whether we in the long run want to allow known-size tensors for known-rank inputs.

We should yes (that does make the above more complicated)

mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
394

I don't understand the tuple part, did you mean type?

395

Doesn't it just return the shape?

396

But this also can take a ValueShapeType as input and that can be an error already (e.g., you can invoke one shape func from another, we need to discuss the create function there we haven't gotten to it in the last couple of syncs, I should try and implement today so that we can discuss with code).

Only when input is just a ShapedType is no error possible. It would therefore seem that this one has:

ValueShapeType -> !shape.shape
ShapedType -> tensor<?xindex>

With it being legal but canonicalized away to have ShapedType -> !shape.shape during lowering.

rriddle added inline comments.Jul 20 2020, 10:33 AM
mlir/lib/Dialect/Shape/IR/Shape.cpp
27

Why is this being marked as inline? Also, static functions should not be in anonymous namespaces and should be marked as 'static' instead.

frgossen retitled this revision from [MLIR][Shape] Change type of `shape_of` from `shape` to extent tensor to [MLIR][Shape] Allow for `shape_of` to return extent tensors.Jul 21 2020, 6:55 AM
frgossen edited the summary of this revision. (Show Details)
frgossen updated this revision to Diff 279511.Jul 21 2020, 7:07 AM
frgossen marked 2 inline comments as done.

Address comments

frgossen marked 6 inline comments as done.Jul 21 2020, 7:12 AM
frgossen added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
394

The documentation for value_shape says "Conceptually this is a tuple of a value (potentially unknown) and shape.type". I thought calling it a value-shape tuple would help in the description. Apparently it doesn't.

395

It can return a shape (shape.shape) or an extent tensor (tensor<?xindex>)

396

I did not fully understand the value_shape it seems. The operation now allows for both variants.
Would the variant "ShapedType -> !shape.shape" ever be useful? Eventually, all operations will accept extent tensors.

frgossen marked 3 inline comments as done.Jul 21 2020, 7:13 AM
jpienaar accepted this revision.Jul 23 2020, 2:32 PM
jpienaar marked an inline comment as done.
jpienaar added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
396

Only as intermediate form really that I can think of. And even there it is dubious, as it would reified with the correct type ...

mlir/lib/Dialect/Shape/IR/Shape.cpp
643

Up to you, but I'd relax this one as the above loses info, while this one is just overly broad. BUT I can't really think in practice where this would happen - I can think of convoluted ways it could happen ... But none that I see us using.

This revision is now accepted and ready to land.Jul 23 2020, 2:32 PM
This revision was automatically updated to reflect the committed changes.
frgossen marked an inline comment as done.