Re: Help with define_insn and constraints

[Robert Baruch <autophile at gmail dot com>]

> This kind of thing happens because gcc decides to do
>     (set (mem:QI (plus:QI (reg:QI pseudo) 1)) (reg:QI 4))
> and then puts the pseudo on the stack and replaces it with
>     (mem:QI (plus:QI (reg:QI fp) 104))
> 
> Typically this kind of thing will wind up in gen_reload() in
> reload1.c.  That code has some heuristics to try to handle the case of
> reloading an address which is a sum.  When it can't figure out what to
> do, it just emits a move insn and hopes for the best.  So I would
> start by putting a breakpoint on gen_reload() and see if this case is
> winding up there, and see what it does.
> 
> If that is the problem, the usual fix is to define
> LEGITIMIZE_RELOAD_ADDRESS to do something clever with frame pointer
> references.

Well, after stepping through reload() a bunch of times, I determined
that first, the original instruction looks like this:

[ P56 + 1 ] <- [ R20 + 17 ]

where P56 is a pseudoreg, and R20 is my frame pointer.

In line 840 of reload1.c (this is gcc-3.4.3, BTW, and it's during the
global reload phase), alter_reg is called for every psuedoreg. This
sets the reg_equiv_memory_loc for P56 to R20 + 104. I didn't see
anything in alter_reg which looks at the actual instruction, so there
doesn't appear to be a chance in alter_reg to prevent this
substitution from happening.

A little further down in reload(), at line 923, there's a loop over
the pseudoregs again, setting reg_equiv_mem for P56 to [ R20 + 104 ].
Again, there doesn't appear to be a chance to prevent this.

Finally, at line 1108 there's a final loop over the pseudoregs, this
time replacing all references to P56 with [ R20 + 104 ], again
apparently without any chance of preventing.

So I'm not sure where to look next.

Thanks for your help...

--Rob