This is an archive of the discontinued LLVM Phabricator instance.

[MLIR] Add `from_index`, `to_index`, and `num_elements` to the shape dialect
AbandonedPublic

Authored by frgossen on May 15 2020, 6:29 AM.

Details

Summary

num_elements derives the number of elements from a given shape.
The remaining operations help with conversion between the shape and the standard
dialect types.

Diff Detail

Event Timeline

frgossen created this revision.May 15 2020, 6:29 AM
Herald added a reviewer: jpienaar. · View Herald Transcript
Herald added a reviewer: silvas. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
silvas added inline comments.May 15 2020, 11:35 AM
mlir/lib/IR/Builders.cpp
57 ↗(On Diff #264224)

can you split this cleanup of the core infra into a different patch?

silvas added inline comments.May 15 2020, 11:38 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

These should be marked NoSideEffect and have folders and InferTypeOpInterface. See https://reviews.llvm.org/D79833 for an example of another op.

pifon2a added inline comments.May 18 2020, 12:17 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

I am not sure from_index is enough. In the IR i first read it as if it creates 1D shape with the provided number number of elements. Maybe call this from_index_rank?

Is there some special reason why we have shape.size instead of shape.rank?

herhut added inline comments.May 18 2020, 3:05 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

Maybe index_to_size and size_to_index would better convey what this does. We could also have a single operation size_cast in the spirit of the index_cast operation in standard that allows both conversions. That would be more uniform and, if we get to a state where we can have a type trait that would allow to use 'index_cast', it would be easier to rewrite.

frgossen marked 3 inline comments as done.May 18 2020, 3:59 AM
frgossen added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

@silvas NoSideEffect makes perfect sense and I will also add the folders where possible.
Can you explain what the InferTypeOpInterface is good for?
I can copy and adapt the code, of course, but I would like to understand its benefit.
Is the return type of, e.g., Shape_FromIndexOp not already known from the declaration outs Index:$result?

@pifon2a As far as I understand it, shape.size is used to describe also but not only the rank of a tensor.
The shape.reduce example, e.g., already uses it to represent the number of elements.
Until now I thought of shape.size as shape's equivalent to size_t.
The name from/to_index was meant to be analogous to from/to_extent_tensor and index was supposed to refer to std's index.
Would from/to_std_index be a better name?

mlir/lib/IR/Builders.cpp
57 ↗(On Diff #264224)

It's now in https://reviews.llvm.org/D80111
I will remove the change here.

silvas added inline comments.May 18 2020, 11:59 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

I would prefer to have two ops rather than an SizeCast that does everything. That way you can just do isa<SizeToIndexOp> and know what you have. Otherwise, you always have to do isa<SizeCastOp> && op.getResult().getType().isa<SizeType>() or other such nonsense. Personally I think that shape.size_from_index/shape.size_to_index is reads best to me

InferTypeOpInterface avoids needing to redundantly write the result type in the builder calls, since for these ops the result type is already known. (MLIR infra should be smarter about this and do it automatically, but currently that's not the case)

herhut added inline comments.May 19 2020, 2:06 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
175

size_from_index size_to_index works for me, too.

frgossen updated this revision to Diff 264840.May 19 2020, 3:38 AM
frgossen marked an inline comment as done.

Rename and constant folding

frgossen marked 6 inline comments as done.May 19 2020, 3:41 AM
frgossen added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
214

Corrected shape.type to shape.shape and fixed line breaks because the containing line was too long.

pifon2a accepted this revision.May 19 2020, 8:34 AM
jpienaar accepted this revision.May 19 2020, 12:43 PM
jpienaar marked an inline comment as done.
jpienaar added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
156

Could we keep these sorted?

175

Can you explain what the InferTypeOpInterface is good for?

It is used to generate custom build and verify methods for ops (and pattern rewrites).

I can copy and adapt the code, of course, but I would like to understand its benefit.
Is the return type of, e.g., Shape_FromIndexOp not already known from the declaration > outs Index:$result?

In this case yes, but not yet plumbed through (there is pending item in shape inference doc about this but hasn't been implemented yet - the goal is to have all the shape constraint solving be in one place and be reused). In general these have been type constraints (e.g., Tensor<IntegerType> could be a case so one doesn't have exact shape/type). We should make it easier/better as Sean mentioned.

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

It would seem for these,

if (Attribute arg = operands[0]) return arg;
return {};

is simpler.

silvas requested changes to this revision.May 19 2020, 8:19 PM

For future reference, this patch should probably be multiple separate patches:

  1. moving ConcatOp
  2. adding size_to_index and size_from_index
  3. adding num_elements
  4. Tidying up docs of Shape_JoinOp and Shape_ReduceOp and Shape_ConstSizeOp
  5. the change to StandardTypes.h

That helps keep each review focused which results in much better review feedback. It also helps people retroactively working through the code history to understand the development process, or folks trying.

I would appreciate if you do it for this patch already; I think there's more feedback to be gotten that is being masked by the mix of stuff happening in this patch. At the very least the commit description needs to be updated to incorporate the fact that it is doing all this stuff.

mlir/test/Dialect/Shape/canonicalize.mlir
119

For this specific test, you might want to specifically check that the value is returned directly (otherwise the test also passes if no transformation is made)

128

You don't seem to use these captured FileCheck variables.

This revision now requires changes to proceed.May 19 2020, 8:19 PM
frgossen marked 8 inline comments as done.May 20 2020, 2:26 AM

As suggested by @silvas , this revision is now split up into multiple ones:

mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
156
mlir/lib/Dialect/Shape/IR/Shape.cpp
312
mlir/test/Dialect/Shape/canonicalize.mlir
119
128
frgossen abandoned this revision.May 20 2020, 2:26 AM
frgossen marked 4 inline comments as done.