This is the mail archive of the gcc-patches@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: Committed: CRIS IRA_COVER_CLASSES definition


On Mon, 29 Sep 2008, Vladimir Makarov wrote:
> Hans-Peter Nilsson wrote:
> > CRIS v32 (a CRIS variant) has a register named ACR (a singleton
> > class ACR_REGS) used as the destination in some three-operand
> > instructions variants for common operations such as additions.
> > Except for that and the inability to be postincremented, it's
> > otherwise like a general register.  Guessing that it'd be
> > beneficial to express the difference through a separate cover
> > class, I thought it'd work to #define IRA_COVER_CLASSES \
> >  { ACR_REGS, GENNONACR_REGS, SPECIAL_REGS, LIM_REG_CLASSES }
> > but that caused a build error for revision 140670:
...
> > Vlad, any hints?  Should I make a PR for this?
> >
> It is an assert checking that register pressure after processing only
> hard-regs available for allocation and living at BB end is not bigger than #
> of available register classes.  I've never seen that this assert failed.  It
> would be interesting for me to look at that.  Could you send me preprocessed
> libgcc2.c file.  I'd look at this and we will decide should we make a PR.

I reconsidered and somewhat proactively entered PR37813 with you
cc:ed, as it's easier to have all facts ready in one place
(preprocessed code, description and discussion).  Feel free to
close as a WONTFIX if you don't think the issue is worthwhile.

> > The (trivial) MMIX update is also in the works, but I saw a
> > regression failure there (gcc.c-torture/execute/20040709-1.c
> > execution, -O2) that I have to look closer at (before I rule out
> > a port bug and blame IRA).

I finally looked a bit closer on this.  A brief look at the
actual miscompiled code makes it seem like IRA doesn't handle
load of paradoxical mem subregs that are constructed by combine
due to LOAD_EXTEND_OP (to wit: implicit sign-extension on load);
a load was "optimized away" when followed by a right-shift of
(register_size - 1) to extract the sign-bit.  More later.

brgds, H-P


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