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: Bug on PA-RISC


Joern Rennecke wrote:
> 
> law@redhat.com wrote:
> > 
> > In message <200206042048.g54KmJk6016494@hiauly1.hia.nrc.ca>, "John David Anglin
> > " writes:
> >  > register copy if reload wasn't so stupid.  Currently, when it finds the
> >  > symbolic mem value that can't be loaded directly to a FPR register, it
> >  > creates a new insn to load the value to a different FPR register (when
> >  > copies aren't disparaged) and then copies the value in the new FPR
> >  > register to the old FPR register.  It doesn't recognize that the new
> >  > insn that it has created has the same problem as the old one.  Somehow,
> >  > we need to get reload to use the address of the MEM when it needs to
> >  > reload a LO_SUM MEM.
> > This would be a bug in how we handle secondary reloads somehow, and while
> > it's possible that we have such a bug, I'd really need more information
> > (dumps, particularly the .lreg and .greg dumps) to figure it out.
> 
> What you want are a reload_indf / reload_outdf expanders, so that you can
> load your register exactly the way you like it.

Oops, I got the problem wrong.
So you get the wrong regster class for your secondary reload.
I see that ALL_REGS is suspiciously absent from FP_REG_CLASS_P.
All register classes that contain one or more FP registers need
to be handled in SECONDARY_RELOAD_CLASS as potentially standing for
a floating point register.

Unless you plainly disallow FP registers for reloads where they don't
make sense.  Perversely, LIMIT_RELOAD_CLASS doesn't really work as
advertised, and you have to use PREFERRED_RELOAD_CLASS instead.


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