[PATCH][testsuite][ARM] Properly figure -mfloat-abi option for crypto tests

[Kyrill Tkachov]

On 13/01/14 13:57, Christophe Lyon wrote:
> Hi Kyrill,
>
> Your patch fixes most of the problems I noticed, however, it makes the
> compiler crash on vld1Q_dupp64 when the target is big-endian:
> --with-target= armeb-none-linux-gnueabihf
> --with-cpu=cortex-a9
> --with-fpu=neon-fp16
>
>
> /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon/vld1Q_dupp64.c:
> In function 'test_vld1Q_dupp64':
> /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon/vld1Q_dupp64.c:16:1:
> error: unrecognizable insn:
> (insn 30 29 16 (set (subreg:DI (reg:V2DI 48 d16 [orig:110 D.14607 ] [110]) 0)
>          (subreg:DI (reg:V2DI 48 d16 [orig:110 D.14607 ] [110]) 8))
> /aci-gcc-fsf/builds/gcc-fsf-trunk/obj-armeb-none-linux-gnueabihf/gcc3/gcc/include/arm_neon.h:8624
> -1
>       (nil))

Hmmm... This seems to be a failure in the vld1Q_dupu64 and vld1Q_dups64 
intrinsics as well that were not part of my crypto patches and were likely 
ICEing before that in big-endian. The problem seems that we end up splitting 
into subregs after register allocation, which causes the ICE. The cuprit is the 
neon_vld1_dupv2di. I think it can be modified to directly use the hard registers 
after reload instead of generating their low and high parts.

I'll test a patch...

Thanks,
Kyrill

> /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon/vld1Q_dupp64.c:16:1:
> internal compiler error: in extract_insn, at recog.c:2168
> 0xa9e560 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/rtl-error.c:109
> 0xa9e59f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/rtl-error.c:117
> 0xa58fef extract_insn(rtx_def*)
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/recog.c:2168
> 0xa592ec extract_insn_cached(rtx_def*)
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/recog.c:2071
> 0x7e5309 cleanup_subreg_operands(rtx_def*)
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/final.c:3074
> 0xa5845f split_insn
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/recog.c:2886
> 0xa585b7 split_all_insns_noflow()
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/recog.c:2991
> 0xe31941 arm_reorg
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/config/arm/arm.c:16962
> 0xa9e240 rest_of_handle_machine_reorg
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/reorg.c:3933
> 0xa9e26e execute
>          /aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/reorg.c:3963
>
>
> Christophe.
>
>
> On 10 January 2014 12:31, Richard Earnshaw <rearnsha@arm.com> wrote:
>> On 09/01/14 17:02, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>> When adding the testsuite options for the crypto tests we need to make sure that
>>> don't end up adding -mfloat-abi=softfp to a hard-float target like
>>> arm-none-linux-gnueabihf. This patch adds that code to figure out which
>>> -mfpu/-mfloat-abi combination to use in a similar approach to the NEON tests.
>>>
>>> This patch addresses the same failures that Christophe mentioned in
>>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00375.html
>>> but with this patch we can get those tests to PASS on arm-none-linux-gnueabihf
>>> instead of being just UNSUPPORTED.
>>>
>>> Tested arm-none-linux-gnueabihf and arm-none-eabi.
>>>
>>> Ok for trunk?
>>>
>>> Thanks,
>>> Kyrill
>>>
>>>
>>> 2014-01-09  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>>>
>>>       * lib/target-supports.exp
>>>       (check_effective_target_arm_crypto_ok_nocache): New.
>>>       (check_effective_target_arm_crypto_ok): Use above procedure.
>>>       (add_options_for_arm_crypto): Use et_arm_crypto_flags.
>>>
>>>
>> OK.
>>
>> R.
>>
>>