This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: s390: SImode pointers vs LR

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)
/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)

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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]