RFR: 8279508: Auto-vectorize Math.round API [v15]

[Jatin Bhateja]

On Sat, 12 Mar 2022 23:20:58 GMT, Quan Anh Mai <duke at 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