RFR: 8266950: Remove vestigial support for non-strict floating-point execution [v2]

David Holmes david.holmes at oracle.com
Sun May 23 22:59:09 UTC 2021


On 24/05/2021 12:13 am, Vladimir Ivanov wrote:
>>> I think there's `result->is_double_fpu()` check missing in 
>>> `FpuStackAllocator::handle_op2`:
>>>
>>>       case lir_mul:
>>>       case lir_div: {
>>>         assert(op2->tmp1_opr()->is_fpu_register(), "strict operations 
>>> need temporary fpu stack slot");
>>>         insert_free_if_dead(op2->tmp1_opr());
>>>         assert(sim()->stack_size() <= 7, "at least one stack slot 
>>> must be free");
>>>         // fall-through: continue with the normal handling of lir_mul 
>>> and lir_div
>>>       }
>>>
>>> The code should be guarded by `result->is_double_fpu()` since special 
>>> handling (additional temp operand) is needed only for `mul`/`div` on 
>>> doubles.
>>
>> Where was that guard on the existing strict version?
>>
>> This failure is suggesting to me that there may be a pre-existing bug 
>> in the strict/non-strict code on x86. I need to check exactly what 
>> cases the failing test is failing on so that I can see which code 
>> change is in play. I have a suspicion but can't check it yet.
> 
> The guard was implicit: `lir_mul_strict`/`lir_div_strict` operations 
> were always instantiated with the temp FPU operand. Since they are 
> removed now, there's aliasing occurring between `lir_mul`/`lir_div` on 
> doubles (`lir_mul_strict`/`lir_div_strict` before) and original 
> operations on ints/longs/floats.

Right I just tracked that through before seeing this email. The fmul 
uses the non-tmp version but later all lir_mul are assumed the same.

Thanks,
David

> So, the check has to be explicit now. Only ddiv/dmul implementations 
> need a temp operand.
> 
> Best regards,
> Vladimir Ivanov


More information about the hotspot-runtime-dev mailing list