This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix DCE REG_LIBCALL note moving from noop move insns (PR rtl-optimization/33644)
On 10/15/07, Eric Botcazou <email@example.com> wrote:
> > As more passes use libcall_id, you simply fix those that are messing
> > it up behind it.
> > This is exactly how we've made every other far reaching change in the
> > backend in the past year.
> > Start somewhere, and slowly expand the reach of it until it is done
> > throughout the entire backend.
> The only thing I can say is that your conception of the maintenance of a
> production compiler sounds a little worrying to me.
"Maintenance of a production compiler"? GCC releases are production
releases. GCC itself has 3 stages of development, not all of which
result in a production quality compiler. This has been true for many
years now. Nobody would claim that the result of stage1 is "a
production quality compiler", and it certainly hasn't been since at
least 4.0. You know this of course, i'm not sure why you are ignoring
it. If you really think the goal of every stage should be to produce
a production compiler, or see your job only as "maintenance of a
production compiler", i would respectfully suggest you need to take a
long look at the history of GCC and how that viewpoint turned out to
> This work should
> have been conducted on the branch before the merge, or at least a clear
> plan should have been discussed with the relevant maintainers before it.
You weren't even an RTL maintainer when this work was discussed.
It *was* in fact, discussed with the relevant maintainers.
The work *was* done on a branch.
Dataflow was a big enough piece of work without adding 73 more
dependencies. Sometimes you have to say "enough is enough" and merge
what you have. If we had kept going, we might as well have just
forked the compiler.