Re: LRA reloads of subregs

[Vladimir Makarov <vmakarov at redhat dot com>]

On 09/03/2015 06:33 PM, David Miller wrote:
> I'm working on converting sparc to LRA, and thanks probably to the
> work the powerpc folks did this is going much better than when I
> last tried this.
Thanks for working on this, David.
> The first major stumbling block I've run into is when LRA forces
> a reload for a SUBREG, and specifically there is a MEM involved
> that itself needs a reload due to having an invalid address.
>
> For example, simplify_operand_subreg() is working on this insn:
>
> (insn 18631 1099 1100 14 (set (reg:SI 13423)
>          (subreg:SI (mem/c:QI (plus:SI (reg/f:SI 101 %sfp)
>                      (const_int -14269 [0xffffffffffffc843])) [0 %sfp+-14269 S1 A8]) 0)) x.c:104 63 {*movsi_insn}
>       (expr_list:REG_DEAD (reg:QI 287)
>          (nil)))
>
> lra_emit_move() (via insert_move_for_subreg()) is called (here, 'reg'
> is the MEM expression).
>
> Because the expression is a MEM, all of the special cased code in
> lra_emit_move() meant to avoid invalid displacements and indexes is
> not used, and it just performs a plain emit_move_insn().
>
> Calling emit_move_insn() does not work properly because it emits code
> which needs reloads, to handle the too large CONST_INT offset in the
> MEM expression.
>
> We abort because lra_process_new_insns() expects everything emitted
> by insert_move_for_subreg() to be recognizable, and with that too
> large offset it cannot.
>
> I wonder why another target's LRA conversion hasn't hit this :-)
I guess the insn should be forced to be recognizable when in 
lra_in_progress is TRUE.  In this case LRA can get insn operands and 
transform them to be valid.

LRA porting frequently needs changing in constraints.md, <target>.c, and 
<target>.md files.
> Vlad I wonder how you'd like this to be handled?  The code to handle
> this kind of situation is there in the process_address infrastructure.
I don't think we should add a new LRA code calling process_address 
before adding insns for further processing.  LRA just needs to get 
operands from insns to make them valid.  So again I'd try to make insn 
recognizable for LRA first and only if it does not work then think about 
other solutions in case when such change creates other problems (it is 
hard for me to predict LRA behaviour definitely just reading source 
files and not knowing sparc port well).