IntVector.fromValues is not optimized away ?

[forax at univ-mlv.fr]

> De: "Paul Sandoz" <paul.sandoz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "panama-dev at openjdk.java.net'" <panama-dev at openjdk.java.net>
> Envoyé: Lundi 11 Mai 2020 22:58:42
> Objet: Re: IntVector.fromValues is not optimized away ?

> I meant replacing the N fields with an an int[] field.
ok, got it. 

> Your use-case is exposing some interesting holes in the code gen, But, I presume
> you are not very serious :-), are you? Given you only have four values to
> reduce.

Are you asking to an academic if what is doing is useful :) 

> Paul.

Rémi 

>> On May 11, 2020, at 1:43 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> wrote:

>>> De: "Paul Sandoz" < [ mailto:paul.sandoz at oracle.com | paul.sandoz at oracle.com ] >
>>> À: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: " [ mailto:panama-dev at openjdk.java.net | panama-dev at openjdk.java.net ] '" <
>>> [ mailto:panama-dev at openjdk.java.net | panama-dev at openjdk.java.net ] >
>>> Envoyé: Lundi 11 Mai 2020 22:31:01
>>> Objet: Re: IntVector.fromValues is not optimized away ?

>>> Grouping the N int fields into an int[] array is likely the most optimal right
>>> now.

>>> We are a bit stuck until HS is enhanced to better track and match source
>>> patterns of element values the vector is composed of. Hence my recommendation.

>>> I doubt N vector insertion instructions will greatly improve matters on their
>>> own, perhaps in combination for fields to avoid the temporary buffer.

>> If i try to create an intermediary array of int, it's not elided by HS
>> By example for this code:
>> var v1 = IntVector.fromArray(IntVector.SPECIES_64, new int[] { i1, i3 }, 0);
>> var v2 = IntVector.fromArray(IntVector.SPECIES_64, new int[] { i2, i4 }, 0);
>> var result = v1.lanewise(VectorOperators.XOR, v2);
>> return result.lane(0) ^ result.lane(1);

>> The first line generates:
>> 0x00007f64d0337e5f: mov 0x120(%r15),%r8
>> 0x00007f64d0337e66: mov %r8,%r10
>> 0x00007f64d0337e69: add $0x18,%r10
>> 0x00007f64d0337e6d: cmp 0x130(%r15),%r10
>> 0x00007f64d0337e74: jae 0x00007f64d0337f62
>> 0x00007f64d0337e7a: mov %r10,0x120(%r15)
>> 0x00007f64d0337e81: prefetchw 0xc0(%r10)
>> 0x00007f64d0337e89: movq $0x1,(%r8)
>> 0x00007f64d0337e90: prefetchw 0x100(%r10)
>> 0x00007f64d0337e98: movl $0x70cb1,0x8(%r8) ; {metadata({type array int})}
>> 0x00007f64d0337ea0: prefetchw 0x140(%r10)
>> 0x00007f64d0337ea8: movl $0x2,0xc(%r8)
>> 0x00007f64d0337eb0: prefetchw 0x180(%r10) ;*newarray {reexecute=0 rethrow=0
>> return_oop=0}
>> ; - fr.umlv.vector.VectorizedHashCode$Data::hashCode2 at 4 (line 38)
>> 0x00007f64d0337eb8: mov 0x14(%rbp),%r11d ;*getfield i3 {reexecute=0 rethrow=0
>> return_oop=0}
>> ; - fr.umlv.vector.VectorizedHashCode$Data::hashCode2 at 16 (line 38)
>> 0x00007f64d0337ebc: mov 0xc(%rbp),%r10d ;*getfield i1 {reexecute=0 rethrow=0
>> return_oop=0}
>> ; - fr.umlv.vector.VectorizedHashCode$Data::hashCode2 at 9 (line 38)
>> 0x00007f64d0337ec0: mov %r10d,0x10(%r8) ;*iastore {reexecute=0 rethrow=0
>> return_oop=0}
>> ; - fr.umlv.vector.VectorizedHashCode$Data::hashCode2 at 12 (line 38)
>> 0x00007f64d0337ec4: mov %r11d,0x14(%r8)
>> 0x00007f64d0337ec8: mov 0x120(%r15),%rax ;*invokestatic extract {reexecute=0
>> rethrow=0 return_oop=0}
>> ; - jdk.incubator.vector.Int64Vector::laneHelper at 16 (line 482)
>> ; - jdk.incubator.vector.Int64Vector::lane at 36 (line 476)
>> ; - fr.umlv.vector.VectorizedHashCode$Data::hashCode2 at 66 (line 41)
>> 0x00007f64d0337ecf: vmovq 0x10(%r8),%xmm1 ;*invokestatic load {reexecute=0
>> rethrow=0 return_oop=0}

>> cheers,
>> Rémi

>>> Paul.

>>>> On May 11, 2020, at 12:59 PM, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>>>> wrote:

>>>>> My recommendation would be to use fromValues for constant or pre-computed vector
>>>>> values.

>>>> and what i should use for fields ?

>>>> Adding pattern matching rules for that in HS can not be done ?

>>>> vmovq + vpxor => vpxor
>>>> vpinsrd + vpxor => vpxor,
>>>> etc