SwiftCompilerSources support for OSSA and lifetime dependence

[atrick]

Fundamental APIs for working with OSSA in swift.

These are both simpler and more complete than the C++ counterpart. I'm adding support for the new on-stack closure representation and handling mark_dependence.

[nate-chandler]

Worth encoding these two possibilities as an enum which scopeEndingOperands is a sequence of?

[atrick]

I encoded EndBorrowOperand as an enum. But there are always unreachable cases here because borrow scopes can now counterintuitively be owned values in the case of partial_apply.

[eeckstein]

nice! I didn't look into all details, yet, but basically it looks good to me.

[eeckstein]

Same here: should this be an enum?
Bonus: the phi argument case could be a struct Phi instead of an Argument

[atrick]

@meg-gupta I'll move InteriorLiveness into its own PR now and work on test cases, so if you have already made fixes then I can cherry pick them into that PR.

[eeckstein]

The first batch of comments: BorrowUtils.
Basically it looks good. Most comments are about documentation, API ergonomics and suggestions for coding style.

Something to consider for future work: My gut feeling tells me that it would be better to represent the borrow-introducer relationship of re-borrows with an explicit instruction in SIL. For example:

bb3(%outer_adjacent_phi : @owned, %inner_adjacent_phi : @guaranteed):
  %v = borrowed %inner_adjacent_phi from %outer_adjacent_phi, %some_dominating_value
  use %v // %v replaces %inner_adjacent_phi in the following SIL

This ensures the dominance relationship of borrow-introducers and makes it easier for passes to obtain this information. The gather-utilities would then be something like SSAUpdater, which can be run by a pass if it changes the SIL.

The borrowed-from instruction is the "moral" OSSA equivalent of a phi-term in plain SSA. Like a phi-term it makes dominance relation a structural property and avoids that passes need to recursively walk the predecessor blocks to gather defs/introducers.

[eeckstein]

Some comments on utilities

[eeckstein]

This is effectively an index. So let's call it Index

[atrick]

ok. but I was avoiding introducing the concept of an Index which would be totally unsafe. The point was that the marker has a scope.

[eeckstein]

The point was that the marker has a scope.

That makes sense. I still would rename it to Index. But make endIndex a private property (and add a comment why it's unsafe when used directly).

[atrick]

I kept this draft open for review comments. It is in sync with the current PR:
#70887

[atrick]

Something to consider for future work: My gut feeling tells me that it would be better to represent the borrow-introducer relationship of re-borrows with an explicit instruction in SIL. For example:

bb3(%outer_adjacent_phi : @owned, %inner_adjacent_phi : @guaranteed):
  %v = borrowed %inner_adjacent_phi from %outer_adjacent_phi, %some_dominating_value
  use %v // %v replaces %inner_adjacent_phi in the following SIL

This ensures the dominance relationship of borrow-introducers and makes it easier for passes to obtain this information. The gather-utilities would then be something like SSAUpdater, which can be run by a pass if it changes the SIL.

The borrowed-from instruction is the "moral" OSSA equivalent of a phi-term in plain SSA. Like a phi-term it makes dominance relation a structural property and avoids that passes need to recursively walk the predecessor blocks to gather defs/introducers.

We've had ongoing discussions about doing this ever since OSSA was introduced. It would obviously simplify OSSA liveness and dead code elimination (although we've finally solved those problems). There are serious tradeoffs though. One is making all passes aware of the borrowed phi dependence. Another problem is figuring out how to guarantee that the dependence always stays valid. Keeping the borrowed phi dependence valid and verifying it requires that same logic we have here, so getting the utilities in this PR right is a good start.

I'm generally in favor of augmenting the SSAUpdater to do more things as an OSSAUpdater. Most importantly, we need to flag phis with lexical lifetimes and pointer escapes because without that, our OSSA utilities all have serious time-complexity problems. If we can also teach OSSAUpdater to update borrowed phi dependencies, that would be reasonable. Then the only question is whether other optimizations might invalidate the borrowed phis in a way the the OSSAUpdater does not catch.

[eeckstein]

One is making all passes aware of the borrowed phi dependence.

That should be encapsulated in the BeginBorrowValue abstraction.

Another problem is figuring out how to guarantee that the dependence always stays valid.

That's what I mean with providing a utility for it (similar to SSAUpdated) which passes can use when they modify the SIL.
It would also make the compiler more efficient because you only have to use the utilities once you modify the SIL and not every time you analyze the SIL.

getting the utilities in this PR right is a good start.

Right 👍

[atrick]

Once #70887 is merged, the LifetimeDependence utils will be introduced in a separate PR.