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

Marc Chevalier mchevalier at openjdk.org
Wed Nov 19 11:09:56 UTC 2025


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

>> 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.

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.

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

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


More information about the hotspot-compiler-dev mailing list