A cast-like operation is one that converts from a set of input types to a set of output types. The arity of the inputs may be from 0-N, whereas the arity of the outputs may be anything from 1-N. Cast-like operations are removable in cases where they produce a "no-op", i.e when the input types and output types match 1-1.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| mlir/lib/IR/Operation.cpp | ||
|---|---|---|
| 1229 | This fold doesn't seem right, as many things that we could consider to be "casts" can be lossy. for example, consider if sitofp and fptosi were a single op (like we do for index_cast an others). Then this could fold away an intermediate truncation to integer. Thoughts? | |
| mlir/lib/IR/Operation.cpp | ||
|---|---|---|
| 1229 | Thanks for the catch, I wrote the builtin op first and then just copied it over. This shouldn't be here. | |
| mlir/include/mlir/Interfaces/CastInterfaces.td | ||
|---|---|---|
| 23 | what is the 0 case? That just seems more like a constant op. | |
| mlir/include/mlir/Interfaces/CastInterfaces.td | ||
|---|---|---|
| 23 | I was thinking of the cases that happen during dialect conversion. During conversion you can end up with a 1->0 conversion (most often during function signature conversion), i.e. where a type gets dropped. If uses of the original value still linger around, we have to insert a cast operation that temporarily materializes that value. | |
Thanks for cleaning this up!
| mlir/test/IR/invalid-ops.mlir | ||
|---|---|---|
| 1077 ↗ | (On Diff #317082) | nit: kind of confusing to see this plural but only used for one type. Would suggest saying type(s). Also, I don't see a test for the multiple-result case, multiple operand case, or 0-operand case. I don't think the anycast patch will include it (it allows all type combinations, right?), so it might be worth adding a test op. |
nice!
| mlir/docs/Tutorials/Toy/Ch-4.md | ||
|---|---|---|
| 224 | Can't this code be simpler, something like: return input && output && input == output && input.hasRank()) since the tensor types are uniqued? You only need the more complicated code if you're using verifyCompatibleShape instead of shape equality IIRC. | |
| mlir/examples/toy/Ch4/mlir/Dialect.cpp | ||
| 249 | same code | |
| mlir/examples/toy/Ch5/mlir/Dialect.cpp | ||
| 249 | same code | |
| mlir/examples/toy/Ch6/mlir/Dialect.cpp | ||
| 250 | same code | |
| mlir/examples/toy/Ch7/mlir/Dialect.cpp | ||
| 301 | same code | |
| mlir/include/mlir/Dialect/StandardOps/IR/Ops.td | ||
| 48–49 | btw Paul taught me that !listconcat(x, y) can be spelled as x # y which is much nicer for this sort of use case | |
| mlir/lib/Dialect/StandardOps/IR/Ops.cpp | ||
| 2740 | Random question, but should this be an assert that input/output.size() == 1 instead of a check? Shouldn't this be called only when the arity is already checked by the verifier? | |
nit: They - The