[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