I read this [RFC] Rename LoopOps dialect to SCF (structured control flow) - #43 by dcaballe But the scf dialect does not seem to contain a switch statement. It also does contain a goto implementation, which is important to implement state machines, such as re2c[1] might generate, espectailly as LLV…

Yup! I’d love to see scf.switch and scf.sign(x) (which has three branches instead of two branches in scf.if, corresponding to x == 0, x < 0, and x > 0). While I agree that optimizing state-machine like code is important, having an explicit FSM dialect with appropriate lowering might also be a good…

I am working on a dialect which includes state machines as a top level construct. A pass then converts this to a number of functions. I think our dialect is a bit domain specific, but in case someone wants to discuss this I would be happy to.

[image] lorrden: A pass then converts this to a number of functions. Not blocks/regions? Do your needs resemble re2c? I am just trying to get a starting point.

Do the conversion passes run in parallel? Cause a switch statement should be converted directly to LLVM until such point that it is possible to create jump tables in the middle end (requires tagging memory locations go the code gen to fill in).

Basically, we have a number of triggers that is the result of external events (we are modelling hardware on a very high level). So our dialect look something like this: func @foobar() ... statemachine foo { ^a: state a {/* entry actions */} { /* exit actions */ } { // Transitions tr…

[image] lorrden: Since our triggers are asynchronous, it is hard to model this with goto-like constructs, and we keep state in a current state variable associated with each state machine. But state machines fundamentally work on an input stream. Look at protothreads Protothreads - Lightweig…

I see the point, and you are right, that would indeed work out as well (I say almost, but I get to that). We ended up at the current solution since it was essentially the natural fit to the source language, which provides interfaces (and simulated timers) for triggering state transitions. So, the tr…

Can you elaborate on this a bit more? which operations are terminator operations? Do you have a notion of state variables which are in-scope in the actions and guards? I’ve been thinking about something like this as part of the circt project: GitHub - llvm/circt: Circuit IR Compilers and Tools …

Quick answers, I will try to write something more elaborate later, maybe on a separate thread. State variables are only available in a “component” which is essentially a class. So member variables only. The exception is parameters to guards and actions, both which handle the arguments to the interf…

I came across this thread while looking at a lowering of mhlo.case to standard control flow. I don’t see scf.switch, but it seems like maybe it should be added. Similarly, should there be sibling op to std.cond_br that would branch to a block based on an index?

Switch statement missing

MLIR

gcmn March 22, 2021, 7:29pm 13

I started an RFC, since I’m proposing adding an op to std: [RFC] Add std.switch and scf.switch

Calyx talk and next steps

Topic		Replies	Views
[RFC] Add std.switch and scf.switch MLIR	25	2369	October 17, 2022
MLIR ‘switch’ op to LLVM dialect Beginners	1	382	August 13, 2021
SCF dialect vs CFG MLIR	1	1472	May 25, 2021
Jump threading for finite state automata LLVM Dev List Archives	0	152	September 29, 2018
[RFC] Rename LoopOps dialect to SCF (structured control flow) MLIR	42	3102	May 6, 2020

Switch statement missing

Related topics