This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
- From: Yury Gribov <y dot gribov at samsung dot com>
- To: ramrad01 at arm dot com
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Julian Brown <julian at codesourcery dot com>, Richard Earnshaw <rearnsha at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, Viacheslav Garbuzov <v dot garbuzov at samsung dot com>
- Date: Mon, 03 Feb 2014 19:14:53 +0400
- Subject: Re: [PATCH, ARM][PING] Reintroduce minipool ranges for zero-extension insn patterns
- Authentication-results: sourceware.org; auth=none
- References: <52E13252 dot 2090900 at samsung dot com> <CAJA7tRbK8wpzVkm_HrNO+b6oiihaxKJ83DyKHKnUXd1CnfQYuw at mail dot gmail dot com>
> Additionally I'm not really sure
> why there is an additional load from the constant pool here - what is
> the constant in this case ?
> Given it is atmost a 16 bit constant
> surely that should be loaded with a single mov(w) instruction
> in armv7 land.
I've made some investigations with 4.8.
The problematic RTL is
(insn 1191 1190 1192 142 (set (reg:SI 1 r1)
(zero_extend:SI (subreg:HI (reg:SI 2606) 0))) svga_tgsi_emit.h:165
165 {*arm_zero_extendhisi2_v6}
(nil))
where RHS expression gets replaced with equivalent constant:
(const_int 1 [0x1])
in find_reloads. This constant is later matched against the constraints
of arm_zero_extendhisi2_v6: "r,m".
"r" fails, "m" succeeds and GCC decides to load constant from constant pool.
This latter causes errors in push_minipool_fix because
arm_zero_extendhisi2_v6 misses the pool_range attributes.
Everything looks reasonable but net result is ICE.
Thoughts?
-Y