This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Loop optimizer issues
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>, Jason Merrill <jason at redhat dot com>, pop at gauvain dot u-strasbg dot fr, Jan Hubicka <jh at suse dot cz>, Daniel Berlin <dberlin at dberlin dot org>
- Date: Tue, 29 Jul 2003 10:56:32 -0700
- Subject: Re: Loop optimizer issues
- References: <20030530183552.GA27110@atrey.karlin.mff.cuni.cz><1054585449.9789.146.camel@frodo.toronto.redhat.com><20030727224601.GA5476@atrey.karlin.mff.cuni.cz><1059492808.3164.61.camel@frodo.toronto.redhat.com>
Diego Novillo <dnovillo@redhat.com> writes:
> I've been thinking about this proposal and I am not convinced that it
> would be a good idea to merge the two branches.
...
You give some good reasons from the point of view of the people
working on the tree-ssa branch.
Unfortunately, I think the larger picture says something different:
* rtlopt is not getting merged into mainline for 3.4 unless we
make a special exception to the rules.
* tree-ssa is slated to be merged very early in 3.5 stage 1.
* At that point tree-ssa may well include the total removal of
the RTL loop optimizer, which would leave rtlopt with nothing
to merge into.
* But tree-ssa can usefully incorporate ideas from rtlopt if
they're made visible to it now.
To me, that says that there are effectively three choices:
* Merge rtlopt into tree-ssa now and deal with the pain.
* Merge rtlopt into mainline now and deal with the pain.
* Throw rtlopt away now.
Given what Zdenek said about the state of play on his branch, I am
inclined toward option 1. I am not opposed to option 2 if we all
agree to make a push and finish fixing the thing on the mainline; this
would have the advantage of getting a better loop optimizer for 3.4
but risks release delays. Option 3 seems like a heinous waste.
zw