RE: [RFC] A policy for supported ports and targets

["S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>]

Richard Sandiford wrote:
> Your main concern seems to be the burden that "unmaintained" ports place
> on the maintainability of target-independent parts of gcc.  And I bet
> many folks agree that's a problem.  It's bad when an old or minor port
> stops developers from improving the rest of gcc.

Yes that is my main concern.  But only part of it.  The other concern
is that many ports in the FSF tree are simply broken, so there is little
point in releasing them in the FSF gcc.  It is as much about quality and
responsability as it is about maintainability.  A maintainer of a port
in the FSF tree should _maintain_ it!


> On the other hand, if an old port _isn't_ stopping developers from doing
> that, I don't see that it matters too much whether the port happens to
> meet some particular standard of being "actively maintained".

This only addresses the first concern.


> It seems unlikely such rules & procedures will
> really help improve maintainability in practice.  Especially since it's
> going to be quite easy to meet these requirements and still have an
> awkward or outdated port that goes "unmaintained" the rest of the time.

On the other hand, there will be test results available so people can see
what the quality of the port is.  And if it is going to be "quite easy"
to meet the requirement of updating the port for obsolete interfaces, then
why is it not happening now?


> On the other hand, points like (1) would probably end up being used to
> browbeat maintainers and lead to unnecessary bad feeling.

So you're saying it is unreasonable to ask of a port maintainer to test 
his/her port every now and then?  To me that seems like a logical thing
to do for a maintainer.


> Why not just have a general principle that, if some port is stopping a
> target-independent improvement to gcc, it can sometimes be OK to make
> the improvement anyway? 
(...)

That still solves only part of the problem.  And I already hear the
protests against the first proposal to do so, regardless of what that
would be.

[ <teaser>
  For example, I would like to propose to make the old pipeline
  description obsolete for GCC 3.5.  You'll hate me an object
  because MIPS still uses it.  But MIPS is basically the only port
  that still uses it (and SH, but a new SH5 description already
  exists, so...).  And there you are!  Even though the new pipeline
  description has been around for more than 2 years in the FSF tree
  (and even longer inside RedHat, it seems), we may end up dragging
  around the old description for at least another two years.
  </teaser> ;-) ]

Having a set of rules for this makes it obvious for the port maintainers
(and for all other developers) what they're up to, and what happens when
they don't maintain the port. 
You can still make a case-by-case exception to the rules, as long as it
is clear that the port will have to be updated or else...


> And, of course, we continue to deprecate ports on a case-by-case basis,
> after a bit of discussion about whether it's the right thing to do.

I'm just proposing a few rules about when this is the right thing to do,
instead of the random picking of targets like we do now.  That does not
mean the case-by-case decisions must go away.  It only provides you with
a framework to decide if a port should be obsoleted or not, and to point
protesters to when they show up again (as they always do) with reasons
why the port is so important to them. "If it's so important to you, then
why is it so poorly maintained?"


> Your message listed:
> 
> > old scheduler model              x1             x         x
> > define_peephole        x              x                    
> > not define_constant    x              x                    
> 
> as bad things for a port to have.  But the lack of define_constants
> in *.md has no impact at all on the general gcc populace.  And I can't
> remember the last time that the presence of the target-independent
> define_peephole code caused problems to ports that don't use it.
> Likewise the old scheduler model.

I agree with your point about define_constants.  It just means that the
port may be more difficult to interpret for other gcc developers.  But
it's neither a real maintainability issue, nor a question of quality.

OTHO, define_peephole is blocking an infrastructure improvement, namely
peephole2.
Likewise the old scheduler model.


> This is a red herring.  If the port doesn't have a scheduling
> description, it's hardly standing in the way of better scheduling code.

True.  But a port without a scheduling description relies on the fact
that insns with no define_function_unit automatically get a latency of 1.
In the DFA pipeline description, any insn that doesn't match an
define_insn_reservation automatically gets a latency of 0.

So moving such ports to the DFA description (without adding a DFA) does
have an effect on code generation, the ports implicitly use the old
scheduler description.

[ The obvious solution is the dummy DFA:
  (define_insn_reservation "dummy" 1 (const_int 1) "nothing")
  or just making the default latency 1.  I don't know if there is
  already code in GCC that relies on the existing default latency. ]


> > An an external tree exists that is better maintained, but in the mean
> > time, the FSF GCC 3.4 was released with a completely broken ip2k port.
> 
> But how many gcc developers _knew_ about the state of the ip2k backend
> before 3.4.0 was released?

The port maintainer did, the release manager did, and anyone who was
looking at gcc 3.4 regressions also did, it was one of the last to be
moved to a later target milestone.


>  And how many cared?  Very few, I bet.

True.  Apparently not even the maintainer cared!


> That indicates to me that the ip2k port wasn't hampering development
> very much.

But the quality of the release was worse for this particular port.  We
are making a promise that gcc is high-quality, yet we're shipping a port
that is completely broken, while at the same time an external tree exists
that does work.  If the maintainers care more about their private tree,
why should the port be in the FSF tree?


> You might be concerned about other things too, like whether it's good
> for users to have the port in the tree when it can be badly broken like
> this.  But I think gcc developers who never use ip2k are the last people
> who should be making judgements about what's good for ip2k users.

So you're saying it's fine to ship a compiler that we know to be broken
like that, and, mind you, not even mentioning it in the release notes?
(BTW that's what my point about pointing to test results in release
notes is for.)


> Remember that gcc changes very quickly,

I'm very much aware if that, and this is why I proposed three releases
before a port could be declared unmaintained.


> When such updates are left to just one person, it's much more of
> a burden

Then we must encourage other developers to help out.  But the initiative
should come from the port maintainer.

For example, I've found it quite easy to contact port maintainers with
questions about their old scheduler description, and many said they had
plans to move to the DFA model sooner or later.  I would much rather
have had that they first try themselves, and then ask for help if they
can't do it.

These proposals are not to bash port maintainers.  It's just as much the
responsibility of other developers who want to move ahead with some
improvement to help out with updating the existing ports.  But again, it
should be the responsibility of the port maintainer to start this work.
After all, for many targets nobody but the port maintainer knows enough
about the internals of the port to work on it.


> and it might take more time to bring the port up to date.
> I don't think it's helpful to impose a fixed time period on that.

No fixed time period is what we have now, and you can see it simply does
not work There has to be a reason for the port maintainers to start
updating ports, and without a fixed time limit, that reason doesn't exist.

So if you _had_ to give a fixed amount of time, what do you think is a
reasonable amount of time?  Like I said in the original mail, I'm not sure
about the details of this part of the proposal.

Gr.
Steven