[code-reflection] RFR: Experiment: Alternative SSA construction algorithm

[Hannes Greule]

On Fri, 16 Aug 2024 16:27:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This should be possible to support, the `Block.Builder::parameters` currently returns an unmodifiable list. I was hesitant about exposing a mutable list, since removing a parameter that is used will create an invalid model. But, we could support removing block parameters that are not currently used nor are any successor arguments associated with them. Although, that probably means it is not very useful.

Yes, that's a restriction that is probably also hard to track, and not restricting removal wouldn't be a good API I think.

> This algorithm really leans on the mutability of a phi node's operand list and user list, and replacement of uses of a phi with another value. I don't see how we can make it work in one pass with the current code model design. However, its still rather good in two passes, better than the Cytron implementation IMO.

I agree. I also think if we want to properly support try-catch-finally constructs with it (as you mentioned), it wouldn't be one pass even if we had mutability. So two passes are probably fine.

> My suggestion would be to lean into the two passes and make the second pass simpler for the resolution of values, for load operation results and additional successor arguments. Its either replacement with another `Value` or a say `BlockParameterHolder` that holds the actual `Block.Parameter` to use. When a `Block` is processed to append the additional block parameters given the list of the holders it will update the holders.

I'll try to improve on that.

> In our current approach it is possible to SSA transform models with nested operations, but the constraint is variables declared outside a body can only be loaded from within a body. This obviously works well for lambdas. But it means we cannot support say the SSA transformation of the high-level model while retaining the structure e.g. the model for this code snippet

I think this is a general problem that comes with the (very powerful) flexibility of the model. It's generally difficult to set boundaries what a valid input code model is for a specific transformation operation, and then there might still be two options: 1) In such case, do not touch that variable and only transform the rest, or 2) throw an exception if an unsupported code element is encountered. Both might make sense in specific scenarios, or both variants could be combined depending *what kind of* unsupported elements are encountered.

----

Without trying hard, I also noticed that the current transform API isn't well-suited when trying to clean up e.g. empty blocks or to combine blocks. Especially with the SSA transform, we end up with unneeded blocks in many places, so I thought that could be a potential improvement, but I didn't find a way to do that without a lot of additional work.

-------------

PR Comment: https://git.openjdk.org/babylon/pull/214#issuecomment-2296668168