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
