RFR: 8371716: C2: Phi node fails Value()'s verification when speculative types clash [v2]

[Emanuel Peter]

On Wed, 19 Nov 2025 10:34:06 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/cfgnode.cpp line 1360:
>> 
>>> 1358:   // same (union of input types), but the new `_type` has now no speculative type, the result of `t->filter_speculative(_type)`
>>> 1359:   // has the speculative type of `t` (if it's not removed because e.g. the resulting type is exact and non null) and not empty
>>> 1360:   // (like the previously returned type). In such a case, doing the filtering one time more allows to reach a fixpoint.
>> 
>>>  From that `ft` has empty speculative type
>> 
>> I'm not very familiar with speculative types. Does "empty speculative" == TOP speculative type? Or rather "no speculative type", which essencially means it is BOTTOM type?
>> 
>> Because then if we filter x with TOP we should still get TOP, but if we filter with BOTTOM we get x. And that would fit better with your statement later on:
>> 
>>> but the new `_type` has now no speculative type, the result of `t->filter_speculative(_type)` has the speculative type of `t`
>> 
>> Can you clarify please for my understanding? :)
>
> And does `cleanup_speculative` happen during `t->filter_speculative(_type)`, right?

I wonder if a minimal example would help here. I'm thinking something like this:

In rare cases, `_type` and `t` have incompatible opinion on speculative type, resulting into a too small intersection
t: Object (A)
_type: Object (B)
We filter them. Since A and B have no intersection, the speculative type is removed. This means the speculative type is implicitly "Object", and not TOP, as the intersection of A and B would suggest.
ft = t->filter_speculative(_type) = Object

After PhiNode::Value, we assign _type = ft. During verification, we run PhiNode::Value again, but this time:
t: Object (A) // same as above
_type: Object // ft from above
And now we get:
ft = t->filter_speculative(_type) = Object (A)

... argue about fixpoint next ...

It is a first proposal, and a little verbose... maybe you could find something more concise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28331#discussion_r2541467689