On Tue, 17 Dec 2024 11:06:17 GMT, Jatin Bhateja <[email protected]> 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
