RFR: 8342103: C2 compiler support for Float16 type and associated scalar operations [v3]

[Emanuel Peter]

On Tue, 17 Dec 2024 11:06:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 275:
>> 
>>> 273:     @IR(counts = {IRNode.ADD_HF, " 0 ", IRNode.REINTERPRET_S2HF, " 0 ", IRNode.REINTERPRET_HF2S, " 0 "},
>>> 274:         applyIfCPUFeature = {"avx512_fp16", "true"})
>>> 275:     public void testAddConstantFolding() {
>> 
>> Ok, this is great. I'm missing some cases that check correct rounding. For that, it might be good to have one example with random constants, so 2 random Float16 values. You can generate them in static context, and also compute the result in static context, so it should be evaluated in the interpreter. That way, we can compare the result of interpreter to compiled code.
>> 
>> Do that for all operations.
>
> Hey @eme64 , constant folding is done at FP32 granularity, so we first upcast FP16 to FP32 values using hf2f runtime helper, operate over FP32 values and then down cast it back to FP16 value using f2hf helper.  Thus both compiler value transformations and interpreter use the same runtime helper underneath.
> 
> Fallback implementation of each Float16 API is using Float.floatToFloat16 and Float.floa16ToFloat routines which are intrinsified at [interpreter level.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp#L488), these interpreter intrinsic invokes same leaf level macro assembly routine flt16_to_flt which is also called though runtime helpers. 
> 
> So it may not add much value to do interpreter vs compiler comparison in these cases.

Ah, yes, you are right, compiler vs interpreter comparison does not help as much as I thought, though we should still do it. What we need to do is compare interpreter and C2-constant-folded results with the results of the backend instructions, but we can also do that with variable values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888838421