Re: s390: SImode pointers vs LR

[Jeff Law <law at redhat dot com>]

On 06/02/2015 09:32 AM, Andreas Krebbel wrote:
> Bootstrap failed with:
>
> /home/andreas/clean/../gcc/gcc/dwarf2out.c: In function ‘constant_size’:
> /home/andreas/clean/../gcc/gcc/dwarf2out.c:6572: error: insn does not satisfy its constraints:
> (insn 39 38 66 6 /home/andreas/clean/../gcc/gcc/toplev.h:176 (set (reg:SI 2 %r2 [orig:44
> prephitmp.4958 ] [44])
>          (ashift:SI (reg:SI 2 %r2 [orig:44 prephitmp.4958 ] [44])
>              (plus:SI (reg:SI 12 %r12 [49])
>                  (reg:SI 2 %r2 [orig:44 prephitmp.4958 ] [44])))) 360 {*ashlsi3} (nil)
>      (nil))
> /home/andreas/clean/../gcc/gcc/dwarf2out.c:6572: internal compiler error: in
> reload_cse_simplify_operands, at postreload.c:393
>
> This is the result of reload reloading the constant in:
>
> (insn 58 57 59 6 (set (reg/v:SI 48 [ log ])
>          (ashift:SI (reg:SI 66)
>              (plus:SI (reg:SI 2 %r2 [+4 ])
>                  (const_int 1 [0x1])))) 360 {*ashlsi3} (insn_list:REG_DEP_TRUE 53
> (insn_list:REG_DEP_TRUE 57 (nil)))
>      (expr_list:REG_DEAD (reg:DI 2 %r2)
>          (expr_list:REG_DEAD (reg:SI 66)
>              (nil))))
>
> Reloads for insn # 58
> Reload 0: reload_in (SI) = (const_int 1 [0x1])
>          ADDR_REGS, RELOAD_FOR_INPUT (opnum = 2)
>          reload_in_reg: (const_int 1 [0x1])
>          reload_reg_rtx: (reg:SI 1 %r1 [66])
> Reload 1: reload_in (SI) = (reg:SI 1 %r1 [66])
>          reload_out (SI) = (reg/v:SI 9 %r9 [orig:48 log ] [48])
>          GENERAL_REGS, RELOAD_OTHER (opnum = 0)
>          reload_in_reg: (reg:SI 1 %r1 [66])
>          reload_out_reg: (reg/v:SI 9 %r9 [orig:48 log ] [48])
>          reload_reg_rtx: (reg/v:SI 9 %r9 [orig:48 log ] [48])
But shouldn't we be reloading the (plus (reg) (const_int 1)) part as a 
whole rather than sub-components?


> Without accepting SImode in s390_decompose_address
> find_reloads_address reloads const_int 1 into a reg.  Unfortunately it
> assumes that this makes a valid address because double_reg_address_ok
> is true on our target. But of course the shift instruction cannot deal
> with an index register.
But isn't that 3 registers used in the address computation if the 
(const_int 1) gets reloaded?  one of the value shifted, two for the 
shift count?  I'm not familiar with the s390, so if you can handle that 
kind of insn, then, umm, cool.



> However, the problem to me appears to be that s390_decompose_address
> is involved for shift count operands at all.  We have a separate
> function for this (s390_decompose_shift_count) which is invoked by the
> relevant predicate and constraint. s390_decompose_address is only
> called because the Y constraint letter is marked as
> EXTRA_ADDRESS_CONSTRAINT.
Note that the EXTRA_ADDRESS_CONSTRAINT stuff all changed a little while 
back, not sure if it makes any significant difference in the analysis 
though.

The only other thing that comes immediately to mind would be secondary 
reloads.  But I always hate suggesting them.


Jeff