This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Address mode offset spill
daniel tian <daniel.xntian@gmail.com> writes:
> Yeah. Now I solve the unrecognize RTL problem. cc1 does not crash. And
> before I add the second_reload macro. There are two problems happened.
> 1. there is a RTL code which move the memory data to another memory
> location. RTL extracted from file *.23.greg :
>
> (insn 128 127 130 7 (set (mem/i:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 28 [0x1c])) [0 nChannels+0 S4 A32])
> (mem:SI (plus:SI (reg/f:SI 14 R14)
> (const_int 11372 [0x2c6c])) [0 iftmp.0+0 S4 A32])) 8
> {store_si} (nil)
> (nil))
>
> this is not allowed in my RISC chip. And This doesn't go through the
> reload macro. Is this need to solve in secondary reload?
This kind of thing will be generated during reload, but should be
cleaned up during reload. If it is not, it suggests that perhaps you
are not checking REG_OK_STRICT as required, or that your predicates or
constraints are wrong. Or there may be some other explanation.
> 2. Here is the RTL code in file *.23.greg:
> (insn:HI 112 218 105 4 (set (reg:SI 5 R5 [78])
> (plus:SI (reg:SI 7 R7)
> (const_int 2064 [0x810]))) 45 {rice_addsi3}
> (insn_list:REG_DEP_TRUE 161 (insn_list:REG_DEP_TRUE 73
> (insn_list:REG_DEP_ANTI 79 (nil))))
> (expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 R14)
> (const_int 2076 [0x81c]))
> (nil)))
>
> which is not legal in my risc chip. In MD file, I 've already defined
> the addsi instruction pattern which only allows the 2nd operand with
> less than 512. I don't know how did this happen. I mean I do know this
> RTL comes from gcc optimization combination, but how it , which should
> be an unrecognizable RTL, becomes recognizable RTL. Does it also need
> the secondary reload macro to handle?
The insn was recognized as rice_addsi3, so take a good look at that insn
and make sure the predicates and constraints reject the 2064.
> And last question, resulted from my gcc4.0.2 porting version, there is
> still no TARGET_SECONDARY RELOAD target hook existance. So I should
> achieve it with the macro SECONDARY_RELOAD_CLASS,
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS. Can anybody give me a hint about
> what 's distinction between SECONDARY_RELOAD_CLASS, and
> SECONDARY_INPUT/OUTPUT_RELOAD_CLASS.
Yes, in gcc 4.0.2 you need to use SECONDARY_RELOAD_CLASS. The docs
explain the difference. I can't recommend using gcc 4.0.2 as a porting
base; newer versions of gcc will generate better code.
Ian