This is an archive of the discontinued LLVM Phabricator instance.

[mlir][GPU] Extend GPU kernel outlining to generate DL specification
ClosedPublic

Authored by dcaballe on Dec 14 2021, 4:42 AM.

Details

Summary

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.

Diff Detail

Event Timeline

dcaballe created this revision.Dec 14 2021, 4:42 AM
dcaballe requested review of this revision.Dec 14 2021, 4:42 AM
herhut accepted this revision.Dec 14 2021, 7:27 AM

Thanks!

It would be nice if we could just pass the data layout as a string.

mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp
309

This is not very satisfactory. Can we parse a data layout from a string @ftynse ?

This revision is now accepted and ready to land.Dec 14 2021, 7:27 AM
mehdi_amini requested changes to this revision.Dec 14 2021, 10:57 AM
mehdi_amini added inline comments.
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.

This revision now requires changes to proceed.Dec 14 2021, 10:57 AM
dcaballe added inline comments.Dec 14 2021, 1:39 PM
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp
309

Sure! What is the best way to do that? Any pointers?

mehdi_amini added inline comments.Dec 14 2021, 4:54 PM
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.

dcaballe added inline comments.Dec 15 2021, 12:53 AM
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?

ftynse added inline comments.Dec 15 2021, 1:25 AM
mlir/lib/Dialect/GPU/Transforms/KernelOutlining.cpp
309

Can we parse a data layout from a string @ftynse ?

I haven't seen a method to do that.

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.

I have the impression that we should use the interface DataLayoutSpecInterface instead of the specific DataLayoutSpecAttr. Can we parse/print a DataLayoutSpecInterface?

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.

dcaballe updated this revision to Diff 394573.Dec 15 2021, 7:49 AM

Addressed the feecback. The data layout spec is now passed using a string.
Much better. Thanks for the feedback!

mehdi_amini accepted this revision.Dec 15 2021, 12:06 PM
This revision is now accepted and ready to land.Dec 15 2021, 12:06 PM
This revision was landed with ongoing or failed builds.Dec 16 2021, 3:38 AM
This revision was automatically updated to reflect the committed changes.