`scf.if` support

[burgholzer]

At the moment, the Jeff spec only defines the following SCF operations (https://github.com/unitaryfoundation/jeff/blob/main/docs/spec.md#structured-control-flow-scfop):

• switch
• for
• while, doWhile

One of the "typical" SCF operations known from MLIR is scf.if.
@dime10 @aborgna-q Is there any reason for not adding this?
We'd be happy to submit a PR that adds it.

[josh146]

@burgholzer I can fill you in on some of the previous discussion from the Xanadu side. @dime10 summarized the status earlier in the year:

While I agree that including all the variants in the MLIR SCF dialect is probably overkill, there is a somewhat significant mismatch between the current proto schema and the SCF dialect:

• for loop: Jeff specifies ranges with only 1 integer (num iterations), SCF has 3 (start, stop, step)

• if-else branch: not present in Jeff, although it can be mapped straight-forwardly to the switch statement. Round-tripping might not preserve it though.

• switch statement: maps closely between the two

• while loop: the semantics are somewhat different here between Jeff and SCF

  • Jeff currently has a traditional do-while loop, which is not ideal for mapping 0 iteration loops as that requires an additional conditional operation

  • The while loop in MLIR is actually more general than either a standard while or do-while, and both can be expressed in it. The op consists of two regions, where the first region ends in a conditional check. Arbitrary code can be placed in either region, so a traditional while loop would look as follows

    while {
        condition(bool)
    } do {
        body...
    }

    while the do-while loop looks like

    while {
        body...
        condition(bool)
    } do {}

    A mixture of the two is also possible.

• Additionally, there is a big structural difference in that all regions in Jeff are isolated from above, while SCF regions in MLIR are not. That is, values can flow into nested regions without being arguments to the container operation. This is why the if operation for example has no additional arguments (besides the condition).

  While I'm pointing out this discrepancy, I don't really see a reason to change this, and having all inflowing edges go through the region-containing op is fine by me.

[josh146]

Still very much an open question though, and something we can choose to adapt and iterate

[dime10]

The summary above is actually from before we made some updates to the SCF ops in jeff. We addressed some of the points, but regarding the if-statement specifically we decided that it wasn't very necessary because you could just represent it as a two-case switch statement, and adding it would thus be fairly redundant. That being said, if there is a stronger preference now to include it for convenience, I have no problems with this!
@aborgna-q what do you think?

[burgholzer]

Just trying to summarize our brief online discussion on this here:
We had a brief discussion on whether it is better to avoid the redundancy introduced by adding a dedicated if statement or to force everyone to write conversions between a two-case switch statement and, e.g., scf.if statements in MLIR.
There were no hard objections for either side, but the general tendency was to add an explicit if statement.
One of the stronger arguments was that we would have to explain to everyone that looks at the format that there is no explicit if, but that people are supposed to use convert to/from switch statements.

I think the other points from the summary above have either been resolved or may be picked up again as part of #4