[jdk16] RFR: 8255763: C2: OSR miscompilation caused by invalid memory instruction placement

Vladimir Kozlov kvn at openjdk.java.net
Thu Dec 17 18:16:00 UTC 2020


On Thu, 17 Dec 2020 07:13:59 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:

>> Changes seems fine. And should be done regardless my following questions.
>> 
>> Is it possible to avoid "hoist inversion" if we take into account BCI and other information instead of only  frequency? Is it possible compute_freq() take into account irreducible loops?
>
>> Is it possible to avoid "hoist inversion" if we take into account BCI and other information instead of only frequency?
> 
> We could avoid it if
> 
> 1) we followed the original heuristic proposed in Click's [Global code motion/global value numbering](https://courses.cs.washington.edu/courses/cse501/04wi/papers/click-pldi95.pdf) paper:
> 
> _"We choose the block that is in the shallowest loop nest possible, and then is as control dependent as possible."_
> 
> and
> 
> 2) we had perfect loop information (including information about irreducible loops).
> 
> Unfortunately, information about irreducible loops is currently discarded when building the CFG-loop tree: 
> 
> https://github.com/openjdk/jdk16/blob/ce0ab2dd848484ad1837536942d42f19a509989b/src/hotspot/share/opto/gcm.cpp#L1657-L1659
> 
>> Is it possible compute_freq() take into account irreducible loops?
> 
> I think so. compute_freq() computes the frequencies of each block within a loop L in a single forward pass (in reverse DFS postorder) over the members (blocks and loops) of L:
> 
> https://github.com/openjdk/jdk16/blob/ce0ab2dd848484ad1837536942d42f19a509989b/src/hotspot/share/opto/gcm.cpp#L1790-L1808
> 
> In this computation, it assumes that the members form an acyclic graph (except for L's back-edges). This assumption does not hold for irreducible graphs, where there might be additional cycles corresponding to non-natural loops.  This could be refined by transforming the single forward pass into a proper system of equations to be solved iteratively. See some more details in the description field of the [bug report](https://bugs.openjdk.java.net/browse/JDK-8255763).

Thank you, @robcasloz
I propose to file RFE to do investigation about discussed improvements.
And proceed with current fix for JDK 16.

I don't see link to testing results in bug report.

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

PR: https://git.openjdk.java.net/jdk16/pull/22


More information about the hotspot-compiler-dev mailing list