[Mlir-commits] [mlir] [MLIR] emitc: Add emitc translation unit op (PR #123298)

Marius Brehler llvmlistbot at llvm.org
Tue Jan 21 08:54:02 PST 2025


marbre wrote:

> Thinking about the semantics of the proposed op, such a file-scope `emitc` op may be useful beyond the functionality introduced by this patch, e.g. for
> 
> (a) Specifying the C dialect the `emitc` code belongs to, e.g. in order for the translator to know how to emit vector types when targeting OpenCL, GCC vector extensions etc.

I think this needs to be modeled in the dialect. With this you wouldn't pass a flag to the emitter but of course the emitter would need to know how to handle those ops with dialect information.

> (b) For offload/launch semantics such as in `gpu.launch_func`/`gpu.module`, which could prove useful for OpenCL, OpenMP etc.

Not sure I see how this is related to a file-scope as proposed by this patch.

> (c) Validation: Utilizing standard op validation to verify that all its internal ops are `emitc` and potentially that these ops and types are valid in its designated C-dialect (e.g. vector types, address spaces, templates).

Adding a validation pass is something I started some time ago but didn't had time to finish. So yes, +1 from me. However, does it influence changed introduced by this patch?

> Would be good to discuss this op's designated uses to make sure we don't introduce backward compatibility later. WDYT?

Makes sense, yes.

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


More information about the Mlir-commits mailing list