This is an archive of the discontinued LLVM Phabricator instance.

[mlir][emitc][mlir-translate] Add support for function attributes in emitc
Needs ReviewPublic

Authored by jfurtek on Jan 5 2023, 3:16 PM.

Details

Summary

This diff adds support for generic function attributes in the EmitC dialect,
along with mlir-translate support for emitting these attributes.

The motivating use case for the changes in this diff is the ability to leverage
the existing EmitC infrastructure for the generation of C code for GPU
targets. A canonical example would be the generation of C code that contains
the __global__ specifier for kernel functions, as used by C/C++ toolchains in
CUDA and HIP programming environments. However, the approach is general enough
to accommodate both standard C/C++ attributes (e.g. static, [[nodiscard]],
...) and platform-specific specifiers (e.g. __declspec(dllexport)), as well as
strings that refer to preprocessor macros in an included header file.

The approach is as follows:

  • Add a (discardable) dense string elements attribute to the EmitC dialect to hold attributes as generic strings
  • Modify the C++ translation code used by mlir-translate to write function attribute strings before the function

Diff Detail

Event Timeline

jfurtek created this revision.Jan 5 2023, 3:16 PM
jfurtek requested review of this revision.Jan 5 2023, 3:16 PM
jfurtek updated this revision to Diff 486695.Jan 5 2023, 3:28 PM
  • Add newline to EOF
jpienaar added inline comments.
mlir/lib/Dialect/EmitC/IR/EmitC.cpp
49

Do we expect arbitrary emitc ops to have this attribute?

jfurtek added inline comments.Jan 5 2023, 6:30 PM
mlir/lib/Dialect/EmitC/IR/EmitC.cpp
49

I don't expect arbitrary emitc ops to have this attribute. At the moment, no emitc ops would have this attribute. It is used exclusively for operations that implement FunctionOpInterface.

IIUC, this function is called for a discardable attribute, which must have a name of the form emitc.some_attribute_name. As func_attr is currently the only discardable attribute in the emitc dialect, any other name would be an error.

Would it be preferable to return success() for an unknown discardable attribute? (It seems like the Linalg implementation returns an error for an unexpected attribute name, but some other implementations of verifyOperationAttribute() (e.g. the gpu dialect) return success().)

bmahjour removed a subscriber: bmahjour.Jan 6 2023, 6:26 AM

I think GPU function support for EmitC may be better off as a GPUToEmitC conversion pass where gpu.func gets converted to func.func. This would subsume the pass you added as well as the changes to the emitter.

There are other aspects of gpu.func (e.g. the attached workgroup memory attributions) that need to get lowered into emitc calls as well which are currently not handled below in the emitter changes. It's easy to imagine needing to pass user-options to this conversion as well, and you probably don't want to try to wire up more flags into the translation step than absolutely necessary.

Other gpu dialect ops would need to get lowered to calls (e.g. gpu.thread_id and associated operations). It makes sense to add a dedicated conversion pass rather than adding more extensions to the emitter.

mlir/include/mlir/Dialect/EmitC/IR/EmitCBase.td
39

I don't think this one and line 41 really belong in EmitC.

mlir/include/mlir/Dialect/EmitC/IR/EmitCTypes.td
75 ↗(On Diff #486695)

Why does it need it's own string type?

mlir/include/mlir/Dialect/EmitC/Transforms/Passes.h
17 ↗(On Diff #486695)

This can be moved to line 32/33 and remove line 18.

25 ↗(On Diff #486695)

You shouldn't need to add this declaration anymore.

mlir/include/mlir/Dialect/EmitC/Transforms/Passes.td
26 ↗(On Diff #486695)

This line (26) can get omitted and the declarations will be generated.

mlir/lib/Dialect/EmitC/IR/EmitC.cpp
52

Why do you want it to be a DenseStringElementsAttr? Can't it just be a normal ArrayAttr of StringAttr?

jfurtek updated this revision to Diff 490268.Jan 18 2023, 12:12 PM
  • Add newline to EOF
  • Remove GPU from EmitC dependencies and remove GPU function attribute pass
  • Revert small differences from original upstream
jfurtek edited the summary of this revision. (Show Details)Jan 18 2023, 12:12 PM
jfurtek marked 3 inline comments as done.

Thanks for driving this! We actually had something similar on our long term roadmap and think something function meta attribute like would be desirable. However, for the omp dialect there it is currently discussed on discourse if to go for an omp.function instead of a dialect attribute, see https://discourse.llvm.org/t/rfc-omp-module-and-omp-function-vs-dialect-attributes-to-encode-openmp-properties/67998. I think the same discussion applies here as well. Instead of having emitc.func_attr together with func.func we might want to have emitc.func?