Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
|---|---|---|
| 425 | The number of operands may not have been verified here yet, lets return failure if there are not 2 operands | |
| 436 | Lets check here that it is one of the given types just as haven't verified (lets chat about that later this week too) Seems like a few of these could be deduped, which would help if we have shared functions here to refactor later. | |
| mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
|---|---|---|
| 425 | Added check for size of operands | |
| mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td | ||
|---|---|---|
| 31–33 | We don't have a formatgter for this yet, but the convention we've been following is to have : ShapeOp on the line in line with the def def Shape_AddOp : Shape_Op<"add", [ in some cases the [ and traits on the next, but mostly it opens on the former. | |
| mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
| 436 | May be a case of missing change upload again , I'll double check | |
| 438 | Mmm, this seems to be the same as return l.front().isa<SizeType, IndexType>() || r.front().isa<SizeType, IndexType>() ? | |
| 1213 | Aren't these the only two allowed types for this operand? | |
Remove the type/size check for operands in inferReturnTypes and addressed the review comments
| mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td | ||
|---|---|---|
| 54 | Perhaps (here and below), Returns when two result types are compatible for this op; method used by InferTypeOpInterface ? | |
| mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
| 433 | Could we make a static helper function and just call it from the others? (this seems like the same code below) | |
| 1203 | If we had lhs.isa<IndexType, SizeType> && rhs.isa<SizeType, IndexType>() but lhs.isa<IndexType> && rhs.isa<SizeType>, then this would fail, but seems fine/non-error. Or am I missing it? | |
| 1275 | Could we just use operands[0].getType() here rather than getting one? | |
We don't have a formatgter for this yet, but the convention we've been following is to have : ShapeOp on the line in line with the def
def Shape_AddOp : Shape_Op<"add", [
in some cases the [ and traits on the next, but mostly it opens on the former.