These represent shape based preconditions on execution of code.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td | ||
---|---|---|
24 | typo "using relying" | |
25 | "They are only used as a structural device in the compiler to maintain ordering." | |
32 | typo Cod | |
399 | def name inconsistent with op name. | |
436 | def name is inconsistent with op name. | |
mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
307 | nit: newline after block comment | |
mlir/test/Dialect/Shape/ops.mlir | ||
71 | Let's move the shape.any into the region? |
Great start. Good to go with comments addressed.
mlir/lib/Dialect/Shape/IR/Shape.cpp | ||
---|---|---|
304 | Please keep these sorted. | |
mlir/test/Dialect/Shape/ops.mlir | ||
73 | This needs updating to the new name for the region. Looking at the example, assuming_region conveys the intent of the op much better. We could even drop the region so that it reads (with some potential later custom assembly form) %res = shape.assuming %w3 do { } : !shape.shape |
mlir/test/Dialect/Shape/ops.mlir | ||
---|---|---|
73 | Done. assuming_all is a bad name I think then (I would expect it to be a multiple input form of assuming). I will revisit that later though. |
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td | ||
---|---|---|
346 | LLVM/MLIR code does not have user name based TODO's typically. |
mlir/include/mlir/Dialect/Shape/IR/ShapeOps.td | ||
---|---|---|
451 | Nit: your doc shows nice example where the syntax isn't generic, could you use the declarative assembly syntax for all these ops? |
typo "using relying"