[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