RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5]

[Emanuel Peter]

On Mon, 26 Jan 2026 16:45:43 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Bhavana Kilambi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Address review comments for the JTREG test and microbenchmark
>>  - Merge branch 'master'
>>  - Address review comments
>>  - Fix build failures on Mac
>>  - Address review comments
>>  - Merge 'master'
>>  - 8366444: Add support for add/mul reduction operations for Float16
>>    
>>    This patch adds mid-end support for vectorized add/mul reduction
>>    operations for half floats. It also includes backend aarch64 support for
>>    these operations. Only vectorization support through autovectorization
>>    is added as VectorAPI currently does not support Float16 vector species.
>>    
>>    Both add and mul reduction vectorized through autovectorization mandate
>>    the implementation to be strictly ordered. The following is how each of
>>    these reductions is implemented for different aarch64 targets -
>>    
>>    For AddReduction :
>>    On Neon only targets (UseSVE = 0): Generates scalarized additions
>>    using the scalar "fadd" instruction for both 8B and 16B vector lengths.
>>    This is because Neon does not provide a direct instruction for computing
>>    strictly ordered floating point add reduction.
>>    
>>    On SVE targets (UseSVE > 0): Generates the "fadda" instruction which
>>    computes add reduction for floating point in strict order.
>>    
>>    For MulReduction :
>>    Both Neon and SVE do not provide a direct instruction for computing
>>    strictly ordered floating point multiply reduction. For vector lengths
>>    of 8B and 16B, a scalarized sequence of scalar "fmul" instructions is
>>    generated and multiply reduction for vector lengths > 16B is not
>>    supported.
>>    
>>    Below is the performance of the two newly added microbenchmarks in
>>    Float16OperationsBenchmark.java tested on three different aarch64
>>    machines and with varying MaxVectorSize -
>>    
>>    Note: On all machines, the score (ops/ms) is compared with the master
>>    branch without this patch which generates a sequence of loads ("ldrsh")
>>    to load the FP16 value into an FPR and a scalar "fadd/fmul" to
>>    add/multiply the loaded value to the running sum/product. The ratios
>>    given below are the ratios between the throughput with this patch and
>>    the throughput without this patch.
>>    Ratio > 1 indicate...
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1940:
> 
>> 1938:       }
>> 1939:   BLOCK_COMMENT("} neon_reduce_add_fp16");
>> 1940: }
> 
> Given that the reduction order is sequential: why do you see any speedup in your benchmarks, comparing scalar to vector performance? How do you explain it? I'm just curious ;)

Also: why not allow a vector with only 2 elements? Is there some restriction here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2728407382