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: LRA reloads of subregs


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).


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