<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Oct 10, 2024, at 8:39 AM, Adam Sotona <adam.sotona@oracle.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;">
<p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: Aptos, sans-serif;">
<b><span style="">From:<span class="Apple-converted-space"> </span></span></b><span style="">Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>><br>
<br>
</span></p>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">> In your modeling approach (ignoring multi-catch for now) I think it may be possible to refer directly to the catch blocks as successors for both exit and enter, thereby avoiding a
level of indirection.</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">I think it would be a good start with significant effect. However, the position of each handler in the exception region stack would be very unclear and
I would implicitly position them out of any stack. It is much simple to calculate which exception regions should each handler re-enter, rather than which regions to exit. It will also make much simpler modeling of variables modified in the try blocks. Exception
regions exit and immediate re-enter after the variable modification fixes the flow graph. <span class="Apple-converted-space"> </span><o:p></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>All I was suggesting is to replace the operand whose operation refers to the catch block as a successor with that successor. (Of course it's not really a successor in the conventional sense for either region enter or exit). Just less moving parts. Unless
I misunderstood something about the behavior of your exception.region operation?</div>
<div><br>
</div>
<div>The exit and re-enter to handle variable modifications is interesting. Although, those variable modifications should covered by the exception region and if we modify the program otherwise are we not changing its behavior? These are constraints where it
is not possible to fully perform an SSA transformation. It would be useful to provide functionality to identify such variables, which leans into knowing the rules of the exception region exit/enter operations. </div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div id="mail-editor-reference-message-container">
<div>
<div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><o:p> </o:p></div>
</div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;">> It would be interesting to expand on your example to include finally</div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
</div>
<div>
<div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Finally blocks are just complex compositions of try/catch blocks (with duplications of the finally block code to all exit points).<o:p></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">When lifting from bytecode I do not recognize try/finally, it would require further analysis to identify specific try/catch structures and lift it to try/finally.<o:p></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;"><o:p> </o:p></span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
I was not referring to lifting back to source. Finally blocks add complexity - the arrangement and quantity of exception regions or exception tables entries.</div>
<div><br>
</div>
<div>Paul.</div>
</body>
</html>