On Thu, 28 May 2026 14:14:14 GMT, Paul Sandoz <[email protected]> wrote:
> > @PaulSandoz @jatin-bhateja Is the goal really to push this before RDP1? And
> > the template testing only after? The template fuzzer will take a few weeks
> > to find hits. So then we basically have no time to fix before the release.
> > I don't want to be responsible for those bugs to end up on our compiler bug
> > dashboard.
> > I would prefer if we could just push it after the fork/branch, add the
> > template fuzzer and give it some months to bake, and have enough time to
> > fix follow-up bugs.
>
> My hope is, with sufficiently good preliminary test results, that we might
> straddle RDP1, with the fuzzer going in quickly afterwards. Sherman is
> running tests with the two PRs, but it sounds like it will not be sufficient
> especially if you want to run the fuzzer in various configurations that
> stress the compiler?
>
Hi @PaulSandoz, @eme64 ,
As mentioned earlier template fuzzer is orthogonal to this PR. This PR already
has multiple layers of in-tree coverage to match existing VectorAPI validation
standards:
- Hand-written JTREG suite extended for Float16Vector across all five
shapes (Float16Vector{64,128,256,512,Max}).
- IR Framework tests covering the intrinsified operations
(ADD/SUB/MUL/DIV/MAX/MIN/SQRT/FMA).
- Mach5 tier1/2/3 testing on Linux/x86_64 (Xueming) and AArch64(Xiaohong),
with Mach5 testing on PR-28002 + PR-30997 also in progress.
Once #30997 lands after this PR, the fuzzer will exercise Float16Vector the
same way it does the other lane types today, and follow-up bugs if any would be
handled the same way we handle other Vector API fuzzer-found .
Lets wait for @xuemingshen-oracle to complete his testing with 30977 and I
agree we can then take a call.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4565413353
