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: [patch] cris: Move predicates to predicates.md.


On Saturday 02 April 2005 17:35, Hans-Peter Nilsson wrote:
> On Sat, 2 Apr 2005, Steven Bosscher wrote:
> > On Saturday 02 April 2005 12:13, Hans-Peter Nilsson wrote:
> > > (This far behind on mailing list reading!)
> > >
> > > On Thu, 17 Mar 2005, Kazu Hirata wrote:
> > > > Attached is a patch to move predicates to predicates.md.
> > > >
> > > > Built cc1 for cris-elf.  OK to apply?
> > >
> > > No, at least not now.  Thank you for your work.  I'll take care
> > > of it sooner or later, but I don't see a specific need for this
> > > transition so this'll have to stand back for some other work.
> >
> > The specific reason is that GCC is trying to remove PREDICATE_CODES,
> > thereby removing Yet Another Duplicated Interface in the machine
> > descriptions.
>
> I know.  I just don't see a specific reason why I should do this
> before other work,

That is not what you said in your reply to kazu.  You just said:
"I don't see a specific need for this transition".  Now you say
you don't see a need _now_.  On the one hand I can understand
this, because not all targets have been converted yet.  But on
the other hand I don't understand it because the patch is here
and ready right now, and as you say yourself:

> because IIUC the PREDICATE_CODES vs. 
> predicates.md is a quite local change;

...so why not just approve the patch?  The reason you give:

> it only affects 
> generators and generated code and it's not like it's blocking
> other work in GCC.

...is IMVHO just wrong.  As long as there are ports that still use
PREDICATE_CODES, these ports block cleaning up everything related
to PREDICATE_CODES (which may not be that much, but still, every
unfinished transition is a bad one), so rejecting the patch is not
blocking any GCC work right now, but pretty soon when other ports
are converted, it _will_ be blocking some other work in GCC.  Maybe
by then you would approve a similar patch, but why wait for all
other ports to change?  What you say:

> It's just a matter of priority.

...is true.  I wish transitions from an old machine description
interface to a new one would be higher on port maintainers' TODO
lists.  There are so many half-finished transitions from older
interfaces to new ones, and usually it takes a persisting (to
port maintainers) soul to do the work because the port maintainers
often do not give such transitions any attention at all.  See e.g.
the old vs. new scheduler description, where I did all the work;
or the new target options work, where Richard Sandiford does almost
all the work, and port maintainers don't do anything (cris also
still has the now-old TARGET_OPTIONS macros in it, even though it
only has five target options, so it can't be that much work).  I
am happy to see you are now working on RTL epilogue, at least.  It
is another example of an incomplete transition  :-(

> I'll get to  
> it and I'm thankful for Kazu-san's work; I'll probably use this
> patch as is.  I'm puzzled why you think you need to
> condescendingly paint this out to me as an urgent "maintainance"
> (sic) issue.

It just appeared from your reply to Kazu that you were not even
aware that PREDICATE_CODES is deprecated.  I am sorry to see that
even though you _do_ know this, you do not see it as a maintenance
problem.
I did not mean to be condescending in my mail, it just expresses
my frustration with so many poorly maintained (in my definition)
ports.  I appologize for making you feel offended by my mail.

Gr.
Steven


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