This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][Shape] Add `shape.shape_eq` operation
ClosedPublic

Authored by frgossen on Jun 25 2020, 1:56 AM.

Details

Summary

Add shape.shape_eq operation to the shape dialect.
The operation allows to test shapes for equality.

Diff Detail

Event Timeline

frgossen created this revision.Jun 25 2020, 1:56 AM
Herald added a reviewer: silvas. · View Herald Transcript
Herald added a project: Restricted Project. · View Herald Transcript
silvas added inline comments.Jun 25 2020, 9:57 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
137

Should it be SameOperandsAndResultType?

142

What about equality of errors?

148

Having two separate ops almost seems preferable (and is easier to isa/dyn_cast as well):

shape.shape_eq %lhs, %rhs
shape.size_eq %lhs, %rhs

vs

shape.eq %lhs, %rhs : !shape.shape
shape.eq %lhs, %rhs : !shape.size

More redundancy in the latter.

silvas requested changes to this revision.Jun 25 2020, 9:59 AM
silvas added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
148

Also, it is much easier to builder.create with with two separate ops, since with two separate ops the return type can be inferred.

builder.create<shape::ShapeEqOp>(loc, lhs, rhs)
builder.create<shape::SizeEqOp>(loc, lhs, rhs)

vs

builder.create<shape::EqOp>(loc, builder.getType<shape::ShapeType>(), lhs, rhs)
builder.create<shape::EqOp>(loc, builder.getType<shape::SizeType>(), lhs, rhs)

This revision now requires changes to proceed.Jun 25 2020, 9:59 AM
silvas added inline comments.Jun 25 2020, 10:01 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
137

D'oh, sorry. It's i1 result! My bad!

How is the error case going to be propagated then?

(we could also use shape.eq to be the one for shapes, which is a bit shorter than shape.shape_eq; I personally like being a bit more explicit but it's up to you what feels best namingwise)

silvas added inline comments.Jun 25 2020, 10:10 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
148

D'oh, ignore that last comment. It returns i1.

frgossen marked 6 inline comments as done.Jun 25 2020, 12:44 PM
frgossen added a subscriber: herhut.
frgossen added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
142

We could leave it undefined for now (and mention that in the documentation ofc).
Do you have any preferences? @tpopp , @herhut

148

Sounds good to me. I will split it into two.

frgossen updated this revision to Diff 273655.Jun 26 2020, 3:59 AM
frgossen marked 2 inline comments as done.

Move shape.size_eq to other CL

silvas accepted this revision.Jun 26 2020, 10:49 AM

LGTM modulo getting feedback for others on how to define the error cases.

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

@jpienaar thoughts?

For now, we can say it is undefined. (I don't know what "unknown" means in this context)

frgossen retitled this revision from [MLIR][Shape] Add `shape.eq` operation to [MLIR][Shape] Add `shape.shape_eq` operation.Jun 29 2020, 6:57 AM
frgossen edited the summary of this revision. (Show Details)
frgossen updated this revision to Diff 274105.Jun 29 2020, 7:07 AM
frgossen edited the summary of this revision. (Show Details)

Update documentation

herhut added inline comments.Jun 30 2020, 9:02 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
141

This entire unknown is a bit of a mess. I think we have two different concerns that we are trying to model here. One is the representation of partially constant values for constant folding and analysis. That is where the unknown comes in. On the other hand we have the runtime behavior, which does not know the concept of unknown.

Maybe we should separate the two issues and only describe the runtime semantics for the operations in the docs. Have an additional description of the special encoding that we use for constant folding.

That would fix these issues. @jpienaar WDYT?

If any of the inputs is an error, then the result is undefined works for me.

jpienaar added inline comments.Jul 4 2020, 9:20 AM
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
141

You are correct we do. I think there is more than that: there are operations that express constraints and operations that perform computations. And for the former this is useful but for the latter not. Having it expressed consistently is probably less confusion.

This operation being added here is an operation on shapes but express no constraint. And as such does not need to operate in constraint domain or make sense where errors or partial known values are, e.g., this op should be operating on tensor<?xindex>. For expressing constraint you'd have shape.join %0, %1 followed by feeding into a assuming op (currently they only take witness, but the valid bit of shape serves the purpose of witness, so operationally they make sense there to me). While if this operation only makes sense where no errors are possible, then it should only operate there and so take tensor<?xindex> instead.

142

As mentioned in the dialect doc:

all functions that return a shape and take shapes as input, return the invalid shape if one of its operands is an invalid shape

This op cannot be executed in any situation where one of the shapes can be an error. It only makes sense post verification/inside assume. As such, I don't know if if this op provides anything which equality check on tensor<?xindex> doesn't.

148

Also, it is much easier to builder.create with with two separate ops, since with two separate ops the return type can be inferred

Return type can be inferred in either case. As long as one has the requirement that that operands and result type match.

More redundancy in the latter.

Textual form is meant for debugging only. There is no more or less redundancy in the actual IR. This is still an IR and not a programming language.

frgossen updated this revision to Diff 277347.Jul 13 2020, 2:04 AM

Reflect comments and email discussion

frgossen marked 4 inline comments as done.Jul 13 2020, 2:16 AM
frgossen added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td
142

I could not find an equality check on tensors in std (at least not with a lowering).
Having this operation in the shape dialect also keeps it a bit more closed (@herhut).

frgossen updated this revision to Diff 277430.Jul 13 2020, 7:38 AM

Clarify documentation

silvas requested changes to this revision.Jul 13 2020, 10:12 AM
silvas added inline comments.
mlir/include/mlir/Dialect/Shape/IR/ShapeBase.td
112 ↗(On Diff #277430)

Let's wait before we discuss this more before we add support for both types in the same op. I don't think we have consensus on the direction for this.

This revision now requires changes to proceed.Jul 13 2020, 10:12 AM
herhut accepted this revision.Jul 15 2020, 3:13 AM

I think this is ready to land after yesterday's discussion.

frgossen updated this revision to Diff 278129.Jul 15 2020, 3:28 AM

Correct linebreaks

frgossen marked 3 inline comments as done.Jul 15 2020, 3:29 AM
This revision was not accepted when it landed; it landed in state Needs Review.Jul 15 2020, 3:31 AM
This revision was automatically updated to reflect the committed changes.