[jdk17] RFR: 8269820: C2 PhaseIdealLoop::do_unroll get wrong opaque node [v2]
Roland Westrelin
roland at openjdk.java.net
Mon Jul 12 13:02:10 UTC 2021
On Mon, 12 Jul 2021 10:46:36 GMT, Hui Shi <hshi at openjdk.org> wrote:
>> Have you considered preventing split-thru-phi with an opaque input? That would be a better fix IMO.
>
> @rwestrel sorry for late update, I did detail checks about how opaque1 get cloned in loop optimization. Preventing split-thru-phi with an opaque input doesn't work in my investigation.
>
> ![image](https://user-images.githubusercontent.com/70356247/125274735-d4a61b80-e340-11eb-9b78-ed2d87987c43.png)
> IdealGraph in http://cr.openjdk.java.net/~hshi/8269820/loop_unroll.xml
>
> 1. Opaque1 node is not split in split_thru_phi, it is split when split if in split_up.
> 2. Entire split is triggered by Split if on if node 415
> 3. Split starts at region node 210 and phi node 213, PhaseIdealLoop::split_up from 213->492->497(recursive to 516)->516->499->458
> 4. If disable split 458 in PhaseIdealLoop::split_up, it will crash with other assertions, because "do_split_if" expects "have no instructions in the block containing the IF".
@huishi-hs Thanks for exploring this fix. I still think blocking split thru phi is the way to go. Otherwise there's a risk that the Opaque1 ends up behind a Phi which would break the pattern entirely. This would require something like this:
https://github.com/rwestrel/jdk17/commit/e6d6ebecba478d0a080954494b927d4243ca2ee4
-------------
PR: https://git.openjdk.java.net/jdk17/pull/208
More information about the hotspot-compiler-dev
mailing list