[AArch64] [BE] Fix vector load/stores to not use ld1/st1

[Christophe Lyon]

On 6 November 2014 10:28, Alan Hayward <alan.hayward@arm.com> wrote:
>
>
> On 06/11/2014 09:09, "Yangfei (Felix)" <felix.yang@huawei.com> wrote:
>
>>> On 10 October 2014 16:19, Alan Hayward <alan.hayward@arm.com> wrote:
>>> > This patch is dependant on "[AArch64] [BE] [1/2] Make large opaque
>>> > integer modes endianness-safe.”
>>> >
>>> > It fixes up movoi/ci/xi for Big Endian, so that we end up with the lsb
>>> > of a big-endian integer to be in the low byte of the highest-numbered
>>> > register.
>>> >
>>> > movoi uses stp/ldp
>>> > movxi needs a split version (which is shared with register->register
>>> > movxi), which just splits to two new movs movci can then split to
>>> > three movs. A future patch will instead split to an movoi and a movti.
>>> >
>>> >
>>> > There are no changes for LE.
>>> >
>>> > Ran whole of check with both parts of "Make large opaque integer modes
>>> > endianness-safe”. No regressions.
>>> >
>>> >
>>> > ChangeLog:
>>> >
>>> >     gcc/:
>>> >     2014-10-10  Alan Hayward  <alan.hayward@arm.com>
>>> >         * config/aarch64/aarch64.c
>>> >         (aarch64_classify_address): Allow extra addressing modes for
>>>BE.
>>> >         (aarch64_print_operand): new operand for printing a q
>>>register+1.
>>> >         (aarch64_simd_emit_reg_reg_move): replacement for
>>> >         aarch64_simd_disambiguate_copy that plants the required mov.
>>> >         * config/aarch64/aarch64-protos.h
>>> >         (aarch64_simd_emit_reg_reg_move): replacement for
>>> >         aarch64_simd_disambiguate_copy.
>>> >         * config/aarch64/aarch64-simd.md
>>> >         (define_split) Use new aarch64_simd_emit_reg_reg_move.
>>> >         (define_expand "mov<mode>") less restrictive predicates.
>>> >         (define_insn "*aarch64_mov<mode>") Simplify and only allow
>>>for LE.
>>> >         (define_insn "*aarch64_be_movoi") New.  BE only.  Plant ldp or
>>> stp.
>>> >         (define_insn "*aarch64_be_movci") New.  BE only.  No
>>> instructions.
>>> >         (define_insn "*aarch64_be_movxi") New.  BE only.  No
>>> instructions.
>>> >         (define_split) OI mov.  Use new
>>> aarch64_simd_emit_reg_reg_move.
>>> >         (define_split) CI mov.  Use new
>>> aarch64_simd_emit_reg_reg_move.
>>> > On BE
>>> >         plant movs for reg to/from mem case.
>>> >         (define_split) XI mov.  Use new
>>> aarch64_simd_emit_reg_reg_move.
>>> > On BE
>>> >         plant movs for reg to/from mem case.
>>> >
>>>
>>> OK /Marcus
>>
>>
>>Hello,
>>
>>  It seems that this patch breaks the compile of some testcases under
>>big-endian.
>>  On example: testsuite/gcc.target/aarch64/advsimd-intrinsics/ vldX.c
>>  Any thing I missed? Please confirm. Thanks.
>>
>>$ aarch64_be-linux-gnu-gcc vldX.c
>>
>>vldX.c: In function 'exec_vldX':
>>vldX.c:686:1: internal compiler error: in change_address_1, at
>>emit-rtl.c:2096
>> }
>> ^
>>0x73b18c change_address_1
>>        /home/jjj/p660/p660_build_dir_be/src/trunk/gcc/emit-rtl.c:2096
>>0xdbd278 gen_split_2991(rtx_insn*, rtx_def**)
>>
>>/home/jjj/p660/p660_build_dir_be/src/trunk/gcc/config/aarch64/aarch64-simd
>>.md:4436
>>0x743aa1 try_split(rtx_def*, rtx_def*, int)
>>        /home/jjj/p660/p660_build_dir_be/src/trunk/gcc/emit-rtl.c:3639
>>0x9b8c93 split_insn
>>        /home/jjj/p660/p660_build_dir_be/src/trunk/gcc/recog.c:2901
>>0x9b8ee7 split_all_insns_noflow()
>>        /home/jjj/p660/p660_build_dir_be/src/trunk/gcc/recog.c:3042
>>Please submit a full bug report,
>>with preprocessed source if appropriate.
>>Please include the complete backtrace with any bug report.
>>See <http://gcc.gnu.org/bugs.html> for instructions.
>>
>
>
> Did you try my patch with or without it’s dependency ?
> "[AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.”
> (David Sherwood)
>
> Without that above patch then I would expect some tests to fail.
>

Yes, we already have vldX and vuzp/vzip tests failing in aarch64_be.
They are PR63652 and 636523.

> In addition, it looks like David has had some problems merging that patch
> to the latest head - I’d suggest not using this patch until David has
> sorted his.
I've been looking at these PRs, but I should probably give a try to
David's patch once it's updated.

>
> Alan.
>
>
>