ModuleOp is a natural place to provide scoped data layout information. However,
it is undesirable for ModuleOp to implement the entirety of
DataLayoutOpInterface because that would require either pushing the interface
inside the IR library instead of a separate library, or putting the default
implementation of the interface as inline functions in headers leading to
binary bloat. Instead, ModuleOp accepts an arbitrary data layout spec attribute
and has a dedicated hook to extract it, and DataLayout is modified to know
about ModuleOp particularities.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/docs/DataLayout.md | ||
---|---|---|
30 | ||
194 | I don't under stand the otherwise here. Is it "otherwise if it is a..." ? | |
mlir/lib/Interfaces/DataLayoutInterfaces.cpp | ||
136 | For skip this would need to be a continue. Should this not skip the module op if it is not top-level? So a nested ModuleOp that has no data layout needs to be skipped. |
Address review.
mlir/lib/Interfaces/DataLayoutInterfaces.cpp | ||
---|---|---|
136 | No, it shouldn't. We can have null layouts in the middle and should handle them. It only skips the top-level module because it is most likely the one implicitly added when parsing the IR and using its location is very confusing. And we cannot continue because we are in the lambda. Extended comment to explain this. |
mlir/lib/Interfaces/DataLayoutInterfaces.cpp | ||
---|---|---|
136 | Thank you for clarifying this. |