[vectorInstrinsics] merge with upstream failed

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Jul 6 17:49:12 UTC 2018


Thanks Vlad!

Maurizio


On 06/07/18 16:46, Vladimir Ivanov wrote:
> Pushed. The failures are not caused by the merge.
>
> FAILED: jdk/incubator/vector/Float64VectorTests.java
>
> Missing matcher rules for FmaVF on 2-element float vector:
>   o230  FmaVF === _ o267 o534  [[o331  150 ]]  #vectord[2]:{float}
>
>
> FAILED: jdk/incubator/vector/Long128VectorTests.java
> FAILED: jdk/incubator/vector/Long256VectorTests.java
> FAILED: jdk/incubator/vector/Long512VectorTests.java
>
> Wrong instruction is issued on AVX2-capable CPU.
>
> #  SIGILL (0x4) at pc=0x00000001160a0ab8, pid=95404, tid=8707
>
> # J 801 c2 
> jdk.incubator.vector.Long256Vector.aShiftR(Ljdk/incubator/vector/Vector;)Ljdk/incubator/vector/LongVector; 
> jdk.incubator.vector at 11-internal (6 bytes) @ 0x00000001160a0ab8 
> [0x00000001160a09a0+0x0000000000000118]
>
> According to the x86 architecture manual, only VPSRAVD is available in 
> AVX2, but VPSRAVD is being used by vsrlv2L_reg. Moreover, vsrlv2L_reg 
> and vsrlv2L_reg_evex differ only in predicates.
>
> But there's another issue hidden by the crash - there are no rules for 
> scalar shift on vectors (shift->Opcode() == Op_RShiftCntV).
>
> instruct vsrlv2L_reg(vecX dst, vecX src, vecX shift) %{
>   predicate(UseAVX > 1 && n->as_Vector()->length() == 2 && 
> n->in(2)->Opcode() != Op_RShiftCntV);
>
> Shravya, are those problems known?
>
> Best regards,
> Vladimir Ivanov
>
> On 06/07/2018 03:12, Vladimir Ivanov wrote:
>> I did the manual merge, but then noticed 3 test failures:
>>
>> FAILED: jdk/incubator/vector/Float64VectorTests.java
>> FAILED: jdk/incubator/vector/Long128VectorTests.java
>> FAILED: jdk/incubator/vector/Long256VectorTests.java
>>
>> Haven't checked whether they are new or not. Will push the merge 
>> tomorrow.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 05/07/2018 21:12, Paul Sandoz wrote:
>>> Thanks for the notice.
>>>
>>> I think most if not all of the conflict is associated with the 
>>> base64 intrinsic that was recently pushed:
>>>
>>>    https://bugs.openjdk.java.net/browse/JDK-8205528 
>>> <https://bugs.openjdk.java.net/browse/JDK-8205528>
>>>    http://hg.openjdk.java.net/jdk/jdk/rev/480a96a43b62 
>>> <http://hg.openjdk.java.net/jdk/jdk/rev/480a96a43b62>
>>>
>>> I am not qualified to merge this and there might be some 
>>> architectural issues that need to be resolved regarding the use of 
>>> vector registers for indexing (re: rearrangement using a Shuffle).
>>>
>>> Paul.
>>>
>>>> On Jul 5, 2018, at 4:04 AM, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> Hi,
>>>> the vectorIntrinsics branch failed to merge because of conflicts in 
>>>> assembler_x86.cpp. I tried to look at these, but there seem to be 
>>>> conflicting changes for vector instructions coming from upstream 
>>>> JDK and I was unsure on how to resolve them. I think it's best if 
>>>> people working on this branch take a look at this. To start a merge:
>>>>
>>>> $ hg update vectorIntrinsics
>>>>
>>>> $ hg merge -r default
>>>>
>>>> <do merge>
>>>>
>>>> $ hg commit -m 'manual merge with default'
>>>>
>>>> $ hg push
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>



More information about the panama-dev mailing list