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 <rearn...@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.tkac...@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.
