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 | ||
2984 | 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