[lworld] RFR: 8367245: [lworld] C2 compilation fails with "Missed optimization opportunity in PhaseIterGVN"

[Roland Westrelin]

On Thu, 6 Nov 2025 09:30:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I disagree. The issue only surfaces in this particular occasion does not mean it will not appear in other circumstances, possibly in the future. Even if the code is there on purpose, it seems that the purpose is executed incorrectly.
>> 
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable, which is not the case here. So, another approach may be to fix the injection of speculative and assert that we should not obtain an empty speculative type?
>
>> Additionally, an empty speculative type is supposed to mean that the path is speculatively unreachable,
> 
> Or that profile data for 2 different points in the execution is inconsistent which given how profile data is collected seems as likely to me.
> 
> Speculative types were added as a mechanism to fight profile pollution for scripting languages running on the JVM (specifically nashorn). They work really well in some cases. But they also have limited applicability. To me, it doesn't seem like a good use of developer time or our complexity budget to go with a complicated fix.

> I have looked at the example provided by @rwestrel , and it seems true that when the speculative type is empty, the node is speculatively unreachable (`test1` is always called with `flag1` being `false`, so the return type of `inline2(flag2)` inside the compilation of `test1` is unreachable). Now what can we do with this?

That's how I crafted the test to get conflicting profiles.

I also had to use `TypeProfileLevel=222` to enable some profile collection that's disabled by default. Most compilation wouldn't even see that many speculative types.

Another way to get conflicting profiles would be to make sure profile collection only happens when some particular value is returned and not when some other is returned. Profile collection doesn't start on first execution and stops as soon as a method is compiled by c2. So if a method is called very often, 1) initially returns some type and 2) then only later some other type, and if compilation with c2 happens between 1) and 2), then profile data only reports the type collected in 1).

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

PR Comment: https://git.openjdk.org/valhalla/pull/1717#issuecomment-3496652847