RFR: JDK-8298813: [C2] Converting double to float cause a loss of precision and resulting crypto.aes scores fluctuate

[SUN Guoyun]

On Mon, 19 Dec 2022 06:45:26 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hi all,
>> For C2, convert double to float cause a loss of precision,
>> 
>> <pre><code class="cpp">
>> ./chaitin.cpp:221
>> _high_frequency_lrg = MIN2(double(OPTO_LRG_HIGH_FREQ), _cfg.get_outer_loop_frequency());
>> </code></pre>
>> 
>> Here, _high_frequency_lrg type is float, so maybe has a loss of precision. when it be used:
>> 
>> <pre><code class="cpp">
>> ./coalesce.cpp:379
>> if( lrg._maxfreq >= _phc.high_frequency_lrg() ) {
>>    ...
>> }
>> </code></pre>
>> Here, lrg._maxfreq type is double, so _high_frequency_lrg will be convert double again. But now, due to the loss of precision of _high_frequency_lrg, the conditions here may be true or false.
>> 
>> There are two cases that I tested for SPECjvm2008 crypto.aes.
>> case 1:
>> <pre><code class="shell">
>> //chaitin.cpp:221
>> // fcvt.s.d $f0,$f0 #double->float
>> d = 16.994714324523816
>> f = 16.9947147
>> 
>> //coalesce.cpp:379
>> // fcvt.d.s $f0,$f0 #float->double
>> // fcmp.sle.d $fcc2,$f0,$f1
>> (gdb) i r fa0
>> fa0 {f = 0x0, d = 0x10} {f = -1.08420217e-19, d = 16.994714736938477}
>> (gdb) i r fa1
>> fa1 {f = 0x0, d = 0x10} {f = -7.68722312e-24, d = 16.994714324523816}
>> </code></pre>
>> 
>> case2:
>> <pre><code class="shell">
>> //chaitin.cpp:221
>> // fcvt.s.d $f0,$f0
>> d = 16.996332681816536
>> f = 16.9963322
>> 
>> //coalesce.cpp
>> // fcvt.d.s $f0,$f0
>> // fcmp.sle.d $fcc2,$f0,$f1
>> (gdb) i r fa0
>> fa0 {f = 0x0, d = 0x10} {f = -1.08420217e-19, d = 16.996332168579102}
>> (gdb) i r fa1
>> fa1 {f = 0x0, d = 0x10} {f = -1.73570044e-14, d = 16.996332681816536}
>> </code></pre>
>> 
>> The above two cases result in different block generation（case2 can insert new SpillCopyNodes), and resulting score on cryto.aes is fluctuate.
>> 
>> This is a patch to fix this problem. Please help review it.
>> 
>> Thanks,
>> Sun Guoyun
>
> Tests passed and performance results looks good. I think the other change that you proposed should not be part of this.

@TobiHartmann Thank you for your review. I have one more question for you, How did you test SPECjvm2008 performance?  take the maximum or average value of multiple test results?

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

PR: https://git.openjdk.org/jdk/pull/11685