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

[Marc Chevalier]

On Wed, 19 Nov 2025 11:07:38 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

>> 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.
>
> If we have no speculative type, it means we don't have a guess about what the type could be (more precisely than the actual type). You can say it's bottom, or that it's the same as the non-speculative type. And indeed, if you do `t->filter_speculative(_type)` when `_type` has no speculative type, the result has the same speculative type as `t` except when this one doesn't already pass `cleanup_speculative`, but then, it's still a fixpoint.

I don't see much value in your "minimal example". Isn't it just naming "A" and "B" instead of saying "speculative type of `t`" and "speculative type of `_type`"? I'm not fan of that: that just introduce more symbols, more names that are not in the code.

Also I'm very careful with examples, they are often misleading by giving a feeling that it's exactly how it happens. For instance `Since A and B have no intersection` is not always true, it just needs the intersection to be above centerline, a small enough intersection. I might rephrase later, but it seems you got what is happening and I first need a decision on the solution before spending time in cleanup that might be entirely erased. It seems that the fixpoint way was far from consensual.

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

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