[Mlir-commits] [mlir] [mlir][gpu] Preserve argument attributes during kernel outlining (PR #221465)

[purnima shrivastava]

purnima-nlp wrote:

> > I understand it better now, Thanks for your guidance. I wish to proceed on the filtering technique @fabianmcg is it okay?
> 
> As @FedericoBruzzone mentioned there's no generic interface to determine what's safe. Further, this is a generic pass that is not tied to LLVM, meaning we shouldn't make decisions based on it.
> 
> Unfortunately this means the filtering approach would be restricted to gpu dialect attributes for parameters (eg. something like `gpu.nonnull`), but none of those exist. In other words, the filtering approach is not really possible without establishing semantics for gpu parameter attributes. This requires an RFC and a concrete proposal of the semantics, and how they are expected to behave, eg. how is `gpu.nonnull` handled by LLVM and SPIR-V.
> 
> IMO it's better to amend the op so that we can tag captured operands with their own attr dicts, ie. make the map between captured operands and kernel args explicit, ie. bypass the semantics conversation entirely. This requires a new patch first extending the op.

Thanks, for guiding . I’d wish to work with the second approach: extending `gpu.launch` so captured operands can carry their own attribute dictionaries, and then have kernel outlining transfer those attrs to the corresponding `gpu.func` arguments.

Could you give me a bit more direction on the shape you have in mind for the `gpu.launch` extension? For example, should there be a parallel `DictArrayAttr`/`ArrayAttr` associated with the captured operands, or would you prefer another representation?

Also, am I understanding correctly that this path is intended to avoid the RFC/semantics discussion and can be done as a separate prerequisite patch before updating the outlining PR?


https://github.com/llvm/llvm-project/pull/221465