On Sat, 12 Mar 2022 23:20:58 GMT, Quan Anh Mai <d...@openjdk.java.net> wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8279508: Creating separate test for round double under feature check.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:
>
>> 4022: * the result is equal to the value of Integer.MAX_VALUE.
>> 4023: */
>> 4024: void
>> C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst,
>> XMMRegister src, XMMRegister xtmp1,
>
> This special handling is really large, could we use a stub routine for it?
Good suggestion, but as of now we are not using vector calling conventions for
stubs.
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178:
>
>> 4176: movl(scratch, 1056964608);
>> 4177: movq(xtmp1, scratch);
>> 4178: vbroadcastss(xtmp1, xtmp1, vec_enc);
>
> You could put the constant in the constant table and use `vbroadcastss` here
> also.
>
> Thank you very much.
constant and register to register moves are never issued to execution ports,
rematerializing value rather than reading from memory will give better
performance.
> src/hotspot/cpu/x86/x86.ad line 7297:
>
>> 7295: ins_encode %{
>> 7296: int vlen_enc = vector_length_encoding(this);
>> 7297: InternalAddress new_mxcsr = $constantaddress(0x3F80L);
>
> `ldmxcsr` takes a `m32` argument so this constant can be an `int` instead.
> Also, I would suggest putting the `mxcst_std` in the constant table also.
Correct, if we do so constant emitted will occupy 4 bytes.
FTR we can also improve on the alignment padding for constants such that start
address of next emitted constant aligned based on the constant size. This will
be beneficial for large sized vector constants (32/64 byte) as we can save
cache line split penalty during vector load.
-------------
PR: https://git.openjdk.java.net/jdk/pull/7094
