Provide C API for MLIR standard types. Since standard types live under lib/IR
in core MLIR, place the C APIs in the IR library as well (standard ops will go
into a separate library). This also defines a placeholder for affine maps that
are necessary to construct a memref, but are not yet exposed to the C API.
Details
- Reviewers
stellaraccident rriddle - Commits
- rG74f577845e81: [mlir] expose standard types to C API
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
| mlir/include/mlir-c/StandardTypes.h | ||
|---|---|---|
| 135 | @stellaraccident rank and shape are int64_tin C++ (not unsigned as usual), do we want to keep them as is or use intptr_t instead? | |
| mlir/test/CAPI/ir.c | ||
| 454 | Apparently there is a problem with printing unranked memrefs in non-default memory space. | |
| mlir/test/CAPI/ir.c | ||
|---|---|---|
| 454 | ||
| mlir/docs/CAPI.md | ||
|---|---|---|
| 83 | ||
| 97 | ||
| mlir/include/mlir-c/StandardTypes.h | ||
| 135 | I think these should be int64_t since that is the natural range of the value, regardless of platform. I would apply this rule: the compiler should be able to represent the same program IR regardless of whether it is built with a 32 or 64bit pointer size (within the limit of not being able to express programs that exceed internal limits of data structure sizes). | |
| 141 | I think this is fine as an intptr_t: these relate to the sizes of ir internal data structures. | |
| mlir/include/mlir/CAPI/Wrap.h | ||
| 41 | Shouldn't this be size_t (and I'm the function) | |