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

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912

--- Comment #5 from mpf at gcc dot gnu.org ---
I think there are some relatively serious issues in the riscv backend here.  
What I understand so far:

1) Only floating point modes are allowed in FPRs
2) There is an alternative in the movqi_internal pattern that allows FPR to GPR
moves but from (1) this is impossible. The presence of this alternative skews
the error from LRA. Removing these alternatives changes the LRA error to max
reloads reached.
3) The preferred reload class for riscv is always FP_REGS if the requested
class is ALL_REGS but there is no check to ensure the mode of the expression
being reloaded can go in FP_REGS.
4) LRA always generates reloads as ALL_REGS to start with and refines
5) Therefore a QImode reload can end up trying to reload through an FP_REG
which is completely impossible. I expect similar FPR-GPR alternatives in other
integer move patterns may also be bugs.

           Spilling non-eliminable hard regs: 8
      Creating newreg=182, assigning class FP_REGS to slow mem r182
      Creating newreg=183, assigning class FP_REGS to slow mem r183
  194: r180:QI=r183:QI
      REG_DEAD r102:SI
    Inserting slow mem reload before:
  196: r182:SI=[frame:SI-0x108]
  197: r183:QI=r182:SI#0

Simply removing the preferred_reload_class hook allows LRA to succeed but
presumably it is desirable to try and reload through FPRs for float modes where
possible.

I suspect the preferred_reload_class should be:

static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
  machine_mode mode = GET_MODE (x);
  if ((GET_MODE_CLASS (mode) == MODE_FLOAT
       || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
      && reg_class_subset_p (FP_REGS, rclass))
    return FP_REGS;

  return reg_class_subset_p (GR_REGS, rclass) ? GR_REGS :
         rclass;
}

But it needs a riscv maintainer to comment on what they were trying to achieve
and the constraints on movqi_internal, movhi_internal, movsi_internal need
checking. From my read through of the backend I believe all the alternatives
involving 'f' on these are invalid but I can't be sure.

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