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-compiler-dev
mailing list