[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