Re: Commit policy wrt. to-be-obsolete targets

[law at redhat dot com]

 In message <15607.36403.110454.80366@sibyl.beware.dropbear.id.au>, Ian Dall 
writes:
 > 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 
 > is
 > in:
 > 
 >     #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 ();
 >     #endif
 > 
 > 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
reloads?


 > 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.

jeff