On 03/02/14 15:14, Yury Gribov wrote:
> > 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])
>
No wonder GCC gets blamed for daft code generation.... The expression
should be replaced as a simple move, not a zero_extend of that constant.
If we did that we'd end up with
(set (reg) (const_int 1))
which in this case is a trivial MOV instruction; and in other cases
could at least access a literal pool with a sensible offset from the PC.
Failing to do that means everything goes down-hill from here.
Do we still get into this mess with LRA?
R.
> 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
>
