RFR: 8301489: ShortLoopOptimizer might lift instructions before their inputs [v2]

[Daniel Skantz]

On Mon, 19 Jun 2023 06:30:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Great work investigating this, Daniel!
> 
> From your comments in JBS, it seems that the underlying issue is additional exception edges in the graph that affect dominator computation. Could you elaborate a bit more on that with respect to the example that you provided in the PR description?
> 
> I'm not an expert in C1 though (paging @veresov and @rwestrel as the author of JDK-7153771).
> 
> Thanks, Tobias

Thank you very much for review! 

My understanding is, this might have been introduced in JDK-7153771, where we have extra edges to the exception handler of all successors during dominator calculation -- `Additional edge to xhandler of all our successors`. The client RangeCheckElimination optimization needed this additional information, but the short loop optimization was not updated accordingly. In this specific case, I observed using print debugging and -XX:TraceLinearScanLevel=4, that the dominator of B10 is being calculated as common_dominator(B7, B1). But B1 has dominator B0 because of the extra edge from B14 to B1 (the exception handler of B3). The short loop optimization lifts loop invariant instructions to the dominator of the loop header, which in this case becomes B0.

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

PR Comment: https://git.openjdk.org/jdk/pull/14492#issuecomment-1598357520