This is the mail archive of the gcc@gcc.gnu.org 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: Subject: Reloading failes


> Hi,
> I'm developing a new port of GCC, and do need some help.
>
> I'm getting an unrecognizable insn that I can't get rid of. The recognizable
> insn
> (set (reg:SI 2 r3)
>      (mem/s:SI (plus:SI (reg/v/f:SI 104)
>                         (const_int 4))))
> is changed in reload() in reload1.c. The pseudo register 104 is replaced
> by a memory address, and the result is becoming
> (set (reg:SI 2 r3)
>      (mem/s:SI (plus:SI (mem:SI (plus:SI (reg/f:SI 6 r7)
>                                          (const_int -16)))
>                         (const_int 4))))
> which is an illegal pattern. How can I tell GCC that this pattern isn't
> legal or needs reloading? I have defined SECONDARY_RELOAD_CLASS and GO_IF_LEGITIMATE_ADDRESS,
> but they are only used earlier in the compilation phase.

How does the pattern of the insn in question look like?  Is the original
memory reference actually matched by an operand, or is it the register?
What constraints are you using?

Are indirect memory accesses legal in other cases, or are they generally invalid?
reload1.c:init_reload initializes spill_indirect_levels using memory_address_p,
which uses GO_IF_LEGITIMATE_ADDRESS.

-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658


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