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: gcc-4.5/4.4: Bug in .subreg1 pass?


Denis Chertykov schrieb:
2011/2/26 Georg-Johann Lay <avr@gjlay.de>:

Ok, this is the patch I meant:

http://gcc.gnu.org/viewcvs?view=revision&revision=86842

it allows just Pmode in r29:r28 because of some spill failures in PR15417
and PR12017.

It was a stupid workaround. I think that the problem exists anyway because it's not a port problem.

Denis.

PR41894 is yet another variation of the problem.


Removong the restricting code like so

int
avr_hard_regno_mode_ok (int regno, enum machine_mode mode)
{
  /* Disallow QImode in stack pointer regs.  */
  if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
    return 0;

- /* The only thing that can go into registers r28:r29 is a Pmode. */
- if (regno == REG_Y && mode == Pmode)
- return 1;
-
- /* Otherwise disallow all regno/mode combinations that span r28:r29.
- */
- if (regno <= (REG_Y + 1) && (regno + GET_MODE_SIZE (mode)) >= (REG_Y + 1))
- return 0;
-
if (mode == QImode)
return 1;


  /* Modes larger than QImode occupy consecutive registers.  */
  if (regno + GET_MODE_SIZE (mode) > FIRST_PSEUDO_REGISTER)
    return 0;

  /* All modes larger than QImode should start in an even register.  */
  return !(regno & 1);
}

leads to correct code.

But I don't understand enough of reload/inerts of fp elimination to estimate all undesired side effects.

Maybe someone with more insight in reload can comment on this issue?

Johann


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