This patch extends the GPU kernel outlining pass so that it can take in
an optional data layout specification that will be attached to the GPU
module operation generated. If the data layout specification is not provided
the default data layout is used instead.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp | ||
---|---|---|
309 | Indeed: we should use a serialization/deserialization of the DataLayoutSpecInterface here, otherwise the pass isn't hermetic and won't generate reproducer. |
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp | ||
---|---|---|
309 | Sure! What is the best way to do that? Any pointers? |
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp | ||
---|---|---|
309 | Sure: you can make the option string based, as Stephan suggested, and then you can have separately a DataLayoutSpecAttr member that you initialize by parsing the string in an override of the initialize(MLIRContext *context) method on the Pass itself. If you want to have a constructor that takes a DataLayoutSpecAttr that is fine as well, but this extra constructor should print the DataLayoutSpecAttr into a string and set the option. That way printing the pass pipeline will generate a textual representation that allows to re-create the pass itself. |
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp | ||
---|---|---|
309 | Thanks! That is useful but I was asking about the serialization/deserialization part. I haven't seen a method to do that. Should I use the parser/printer directly? I have the impression that we should use the interface DataLayoutSpecInterface instead of the specific DataLayoutSpecAttr. Can we parse/print a DataLayoutSpecInterface? |
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp | ||
---|---|---|
309 |
It's an attribute, so we can just call mlir::parseAttribute to parse and Attribute::print to print. The latter can take an llvm::raw_string_ostream to print into a string.
It doesn't really matter. The textual IR infra will dispatch the calls to the concrete implementation provided for a specific attribute even if you call it on generic Attribute. For parsing, this will be based on the dialect prefix. The result of parsing is always a generic Attribute, one can dyn_cast it later. |
Addressed the feecback. The data layout spec is now passed using a string.
Much better. Thanks for the feedback!
This is not very satisfactory. Can we parse a data layout from a string @ftynse ?