RFR: 8374889: C2 VectorAPI: must handle impossible combination of signed cast from float [v2]
Emanuel Peter
epeter at openjdk.org
Tue Jan 13 16:25:55 UTC 2026
> I found this bug with the Template Framework (Vector API Library extension): https://github.com/openjdk/jdk/pull/28873
>
> In `VectorCastNode::opcode`, we have an assert that we **cannot** have an `unsigned cast from float`, it would be nonsense.
> https://github.com/openjdk/jdk/blob/2fbe47559e9ba45306bd08c3636647f865a75abd/src/hotspot/share/opto/vectornode.cpp#L1490-L1491
>
> When we intrinsify `VectorSupport.convert`, we get a constant from the VectorAPI, that determines if we have a signed or unsigned cast, and other constants that determine the `from` and `to` types.
>
> At runtime, the VectorAPI implementation can (I assume) never take a path of `unsigned cast from float`.
> But it seems that nothing prevents the VM from compiling such an (unreachable) path.
>
> Here is how I think it happens:
> - `AbstractVector::castShape` creates a `C` conversion (lane-wise conversion). So at runtime, we will take the `C` switch-case in `AbstractVector::convert0`.
> - Profiling can also make the `Z` (lane-wise reinterpret) switch-case live, because of other cast and reinterpret calls that use that code path. And we may not (yet) have proven that the `Z` switch-case is never taken.
> - So we end up compiling the `Z` path, and call `VectorSupport.convert` with types `float` and `long`. And since the `Z` path sees that the from size is smaller than the to size, we get a `UCAST` (zero extension). Hence, we try to intrinsify a vector unsigned cast from float, and hit the assert.
>
> https://github.com/openjdk/jdk/blob/2fbe47559e9ba45306bd08c3636647f865a75abd/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java#L742-L743
>
> That the `Z` path is unreachable for `castShape` seems to be an invariant that only the VectorAPI knows about, and the VM cannot directly know that and determine that it is dead code. Thus, **I propose that we just check for the condition when trying to intrinsify**, and refuse intrinsification if it is violated.
Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
intrinsify with Halt instead
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/29169/files
- new: https://git.openjdk.org/jdk/pull/29169/files/33fec21c..4c717b5a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=29169&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=29169&range=00-01
Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/29169.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/29169/head:pull/29169
PR: https://git.openjdk.org/jdk/pull/29169
More information about the hotspot-compiler-dev
mailing list