This is the mail archive of the
mailing list for the GCC project.
Re: Commit policy wrt. to-be-obsolete targets
- From: law at redhat dot com
- To: Ian Dall <ian at beware dot dropbear dot id dot au>
- Cc: pfeifer at dbai dot tuwien dot ac dot at, thorpej at wasabisystems dot com, zack at codesourcery dot com, gcc at gcc dot gnu dot org
- Date: Fri, 31 May 2002 11:31:33 -0600
- Subject: Re: Commit policy wrt. to-be-obsolete targets
- Reply-to: law at redhat dot com
In message <email@example.com>, Ian Dall
> Gerald Pfeifer writes:
> > On Thu, 30 May 2002, Zack Weinberg wrote:
> > >> I'm trying to help a friend (and PC532 owner :-) rescue the ns32k
> > >> target from being tossed into the bit bucket. [...]
> > > I'd be inclined to say that anyone who wants it can have the
> > > maintainership, and take the obsoletion off the list [...]
> > ...provided that s/he actually shows signs of activity. ;-)
> > That is, just assuming maintainership to rescue a port, but not actually
> > doing anything about that port is not sufficient. Personally, I'm leaning
> > towards handing over maintainership after a first set of patches to the
> > port and documentation (gcc/doc/install.texi) has been submitted.
> I am willing to maintain this port. I was the last person to
> contribute significant input to it, I do still run a pc532 and am in
> the process of trying to get gcc mainline working.
> The remaining problem I have is that I get an abort in find_reloads(). This
> #ifdef HAVE_cc0
> /* If we made any reloads for addresses, see if they violate a
> "no input reloads" requirement for this insn. But loads that we
> do after the insn (such as for output addresses) are fine. */
> if (no_input_reloads)
> for (i = 0; i < n_reloads; i++)
> if (rld[i].in != 0
> && rld[i].when_needed != RELOAD_FOR_OUTADDR_ADDRESS
> && rld[i].when_needed != RELOAD_FOR_OUTPUT_ADDRESS)
> abort ();
> This is on a "seq" insn.
> (set (mem/s:SI (plus:SI (reg/v/f:SI 38)
> (const_int 32 [0x20])))
> (eq:SI (cc0)
> (const_int 0 [0x0])))
> There seems to be a problem in the generic code in so far as it should
> be possible to allocate and use a memory slot (frame pointer relative)
> in this situation. This problem arose soon after I contributed the
> last lot of ns32k changes. Since it seemed to be a problem in generic
> code and I couldn't see how to fix it, I sort of gave up hoping that
> it would be fixed in due course by someone else.
No, it's not a generic bug. How is the compiler supposed to know that the
cc0 value set in a previous insn is not going to be clobbered by the input
> HOWEVER, the ns32k does not change condition codes for "move"
> instructions, so this test should not be needed. As far as I can see,
> NOTICE_UPDATE_CC is not considered here.
Nope. NOTICE_UPDATE_CC is used for something completely different.
> I have concluded that the right solution, for the ns32k at least, is
> it redo the machine description to not use cc0, but instead use a
> special register explicitly updated, used or clobbered by the relevant
> instructions. I don't think this change is hard, but I don't think it
> is trivial either. I'd appreciate pointers as to whether this is on
> the right track before I dive in.
That's on solution. Another would be to keep the cc0 setter and user
as a single insn until after reload, then split them. We used this
scheme on the x86 for a long time until it was converted to not use cc0.