ExceptionRegion modeling issues and proposed improvements

Paul Sandoz paul.sandoz at oracle.com
Mon Oct 14 15:42:15 UTC 2024



On Oct 14, 2024, at 1:00 AM, Adam Sotona <adam.sotona at oracle.com> wrote:



From: Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>

> Ok. I suspect with that approach we can support what we have today and the relaxed form you are proposing e.g. an region exit can either refer to an associated region enter by value or explicitly to the handlers by successor.

I would prefer the only one way, or the interpretation would go crazy (for example enter multiple, exit partially with reference one of the entered handler, and later (or in another flow path) exit by a reference to the enter).
Let's try the only change that exit does not refer to a specific enter but directly to one or more handlers exited (in a reverse enter order).



Ok.




> How would this work with control flow? I think you would need distinct handlers corresponding to each store.

Not necessary, this is already possible for single level try/catch and the above proposed change will enable it also for nested. The handler is still the same, there are just more flow paths leading to it.

> FWIW C2 does not bother with anything fancy, it just treats it as a box that cannot be SSA’ed. This may indicate it may not be worth the complexity.

This fix is not just about broken SSA, the missing flow path breaks any analysis of the affected variables (including correct variable type resolution from code segments).

Ok, but I don’t think you can fix SSA unless you know which handler is associated with which particular store, otherwise there are multiple paths to the handler for different stored values. And… thinking a little more about it even then there is no obvious way of communicating the values like we do in other cases with block arguments and parameters.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/babylon-dev/attachments/20241014/fb956190/attachment-0001.htm>


More information about the babylon-dev mailing list