[Mlir-commits] [mlir] [mlir][emitc][cf] add 'cf.switch' support in CppEmitter (PR #101478)

Marius Brehler llvmlistbot at llvm.org
Thu Aug 1 13:16:40 PDT 2024


marbre wrote:

> I share @simon-camp's and @marbre's concerns about extending the translator. How about the following alternative then: Lower `cf.switch` to a new `emitc.switch` op (which would also be useful for lowering `scf.switch`). Within the `emitc.switch` cases we'll generate `cf.br` ops which the translator already supports. The `cf.br` ops will carry the `cf.switch` cases' block arguments. Similarly, we can lower `cf.cond_br` to the existing `emitc.if` op, leaving the translator to handle only `cf.br` until we model blocks/labels and goto's propely.
> 
> We can implement this in either order:
> 
> * First move the existing `cf.cond_br` support to a new CFToEmitC lowering pass, then add an `emitc.switch` op and extend the pass to lower `cf.switch` into it.
> * First add an `emitc.switch` op with a new CFToEmitC lowering pass which uses it for `cf.switch`, then move the existing `cf.cond_br` support there.
> 
> WDYT?

If an `emitc.switch` option is useful and doesn't not just replicated `cf.switch` but can instead be used to lower to from `scf.index_switch` (I assume you @aniragil were referring to that), I am highly in favor of a new EmitC op. Great suggestion @aniragil!
However, I don't think that we necessarily need to generate `cf.br` ops within an `emitc.switch` op. For me it's fine to partly duplicate logic in the translator while keeping code duplications as low as possible. With that, it could go more into a direction where we could entirely remove support for the `cf` dialect one day.

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


More information about the Mlir-commits mailing list