[FSM][CalyxToFSM] Should `fsm.machine` be IsolatedFromAbove?
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 524
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 46
Description
Based on our docs, `fsm.machine` ops seem to be akin to instances, in that they define a structure that other ops can then instantiate. Based on this, it seems sensible to have the op be IsolatedFromAbove as other modulelike ops are, so the instances aren't implicitly sharing inputs - without this we hit some weird corner cases in our FSM work e.g., where canonicalization lifts ops out of the `fsm.machine` op.
I took a look at changing this over, but it seems like the blocker is CalyxToFSM, which relies on an `fsm.machine` op using values defined outside it. @mortbopet it looks like you wrote that pass - do you think it would be possible to avoid this deisolation? I guess maybe the most sensible ways would either be using an instance op (not sure if that works conceptually with the pass though) or somehow otherwise using the inputs of the FSM machine op to explicitly specify the values to be used (although maybe we'd end up just reinventing the InstanceOp to select the SSA values to be passed to those inputs)? Happy to sort this if either of those sound sensible!
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the CalyxToFSM pass and the fsm.machine operation definition, then compare them with the documented behavior of other module-like operations. Determine whether the pass can avoid external SSA values through explicit inputs or an instance operation, and verify that canonicalization no longer lifts operations across the machine boundary.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100