This is the mail archive of the 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]

LRA reloads of subregs

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.

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)

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

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.

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