>For some reason reload has decided that it needs ADDR_REGS for the
>register being reloaded, namely (reg:QI 1420). So gcc looks for a
>register in ADDR_REGS which can hold QImode. Because of your changes,
>it doesn't find one. So it crashes.
>
>The question is why reload thinks that it needs ADDR_REGS for this
>register. Look at the local-alloc debugging dump to see where
>regclass thinks that the register should go.
Which debugging dump has the output from "local-alloc"? If its
pp_pack.c.24.lreg, then that is the output I supplied in the original
message which contains(for all bits regarding register 1420 up until
the compilation fails):
Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294
ALL_REGS:294 MEM:441
Register 1420 pref DATA_REGS
Register 1420 costs: DATA_REGS:84 GENERAL_REGS:210 DATA_OR_FP_REGS:294
ALL_REGS:294 MEM:441
Register 1420 used 3 times across 6 insns; set 1 time; 1 bytes; pref DATA_REGS.
Registers live at end: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45 46
47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735 1736
1738 1740
Registers live at start: 14 [%a6] 15 [%sp] 24 [argptr] 31 35 36 37 38 39 43 45
46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413 1420 1725 1734 1735
1736 1738 1740
;; Start of basic block 694, registers live: 14 [%a6] 15 [%sp] 24 [argptr] 31
35 36 37 38 39 43 45 46 47 48 50 52 57 70 1369 1370 1371 1378 1391 1402 1413
1725 1734 1735 1736 1738 1740 1756
(note 6967 5556 5558 694 [bb 694] NOTE_INSN_BASIC_BLOCK)
(insn 5558 6967 5559 694 pp_pack.c:2144 (set (reg:QI 1420)
(mem:QI (reg:SI 1756 [ s ]) [0 S1 A8])) 43 {movqi_cfv4} (nil)
(expr_list:REG_DEAD (reg:SI 1756 [ s ])
(nil)))
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 1421)
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffffffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
(nil))
(insn:QI 5560 5559 5561 694 pp_pack.c:2144 (set (cc0)
(compare (subreg:QI (reg:SI 1421) 3)
(const_int 64 [0x40]))) 15 {cfv4_cmpqi} (insn_list 5559 (nil))
(expr_list:REG_DEAD (reg:SI 1421)
(nil)))
BTW: the patterns mentioned in the dump:
(define_insn "movqi_cfv4"
[(set (match_operand:QI 0 "nonimmediate_operand" "=d<Q>,dmU,U,d")
(match_operand:QI 1 "general_src_operand" "dmi,d<Q>,Ui,di"))]
"TARGET_CFV4"
"* return output_move_qimode (operands);")
(define_insn "*addsi3_5200"
[(set (match_operand:SI 0 "nonimmediate_operand" "=m,?a,?a,r")
(plus:SI (match_operand:SI 1 "general_operand" "%0,a,rJK,0")
(match_operand:SI 2 "general_src_operand"
"dIL,rJK,a,mrIKLi")))]
"TARGET_COLDFIRE"
"* return output_addsi3 (operands);")
(define_insn "cfv4_cmpqi"
[(set (cc0)
(compare (match_operand:QI 0 "nonimmediate_operand" "mdKs,d")
(match_operand:QI 1 "general_operand" "d,mdKs")))]
"TARGET_CFV4"
"*
{
if (REG_P (operands[1])
|| (!REG_P (operands[0]) && GET_CODE (operands[0]) != MEM))
{ cc_status.flags |= CC_REVERSED;
#ifdef SGS_CMP_ORDER
return \"cmp%.b %d1,%d0\";
#else
return \"cmp%.b %d0,%d1\";
#endif
}
#ifdef SGS_CMP_ORDER
return \"cmp%.b %d0,%d1\";
#else
return \"cmp%.b %d1,%d0\";
#endif
}")
And the function called for HARD_REGNO_MODE_OK is:
/* Value is 1 if hard register REGNO can hold a value of machine-mode MODE.
On the 68000, the cpu registers can hold any mode except bytes in
address registers, but the 68881 registers
can hold only SFmode or DFmode. */
int m68k_hard_regno_mode_ok(int regno, enum machine_mode mode)
{
if (regno < 8)
{
/* Data Registers can hold anything if it fits into the data registers */
if ((regno) + GET_MODE_SIZE (mode) / 4 > 8)
return 0;
return 1;
}
else if (regno < 16)
{
/* Address Registers, can't hold bytes, can hold aggregate if
fits in */
if (GET_MODE_SIZE (mode) == 1)
return 0;
if (!((regno) < 8 && (regno) + GET_MODE_SIZE (mode) / 4 > 16))
return 1;
}
else if (regno < 24)
{
/* FPU registers, hold float or complex float of long double or smaller */
if ((GET_MODE_CLASS (mode) == MODE_FLOAT
|| GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
&& (((GET_MODE_UNIT_SIZE (mode) <= 12) && TARGET_68881)
|| ((GET_MODE_UNIT_SIZE (mode) <= 8) && TARGET_CFV4E)))
return 1;
}
return 0;
}
Any further insight or suggestions are *really* appreciated!
--
Peter Barada
[EMAIL PROTECTED]
