| Message ID | 52CED61A.9060006@arm.com |
|---|---|
| State | New |
| Headers | show |
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.
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))
/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.
>
>
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. >> >>
On 13 January 2014 15:51, Kyrill Tkachov <kyrylo.tkachov@arm.com> wrote: > 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. > You are probably right; before your patch it failed in my configuration because it was trying to #include gnu/stubs-soft.h in the hf configuration. Since you fixed that, the other problem appeared. > I'll test a patch... > Thanks
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 5166679..f1f4024 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -2301,19 +2301,37 @@ proc check_effective_target_arm_unaligned { } { } # Return 1 if this is an ARM target supporting -mfpu=crypto-neon-fp-armv8 -# -mfloat-abi=softfp. -proc check_effective_target_arm_crypto_ok {} { +# -mfloat-abi=softfp or equivalent options. Some multilibs may be +# incompatible with these options. Also set et_arm_crypto_flags to the +# best options to add. + +proc check_effective_target_arm_crypto_ok_nocache { } { + global et_arm_crypto_flags + set et_arm_crypto_flags "" if { [check_effective_target_arm32] } { - return [check_no_compiler_messages arm_crypto_ok object { - int foo (void) - { - __asm__ volatile ("aese.8 q0, q0"); - return 0; - } - } "-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp"] - } else { - return 0 + foreach flags {"" "-mfloat-abi=softfp" "-mfpu=crypto-neon-fp-armv8" "-mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp"} { + if { [check_no_compiler_messages_nocache arm_crypto_ok object { + #include "arm_neon.h" + uint8x16_t + foo (uint8x16_t a, uint8x16_t b) + { + return vaeseq_u8 (a, b); + } + } "$flags"] } { + set et_arm_crypto_flags $flags + return 1 + } + } } + + return 0 +} + +# Return 1 if this is an ARM target supporting -mfpu=crypto-neon-fp-armv8 + +proc check_effective_target_arm_crypto_ok { } { + return [check_cached_effective_target arm_crypto_ok \ + check_effective_target_arm_crypto_ok_nocache] } # Add options for crypto extensions. @@ -2321,7 +2339,8 @@ proc add_options_for_arm_crypto { flags } { if { ! [check_effective_target_arm_crypto_ok] } { return "$flags" } - return "$flags -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp" + global et_arm_crypto_flags + return "$flags $et_arm_crypto_flags" } # Add the options needed for NEON. We need either -mfloat-abi=softfp
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.