This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Use of build_binary_op
Op do 26-09-2002, om 15:02 schreef Jason Merrill:
> On 26 Sep 2002 13:30:17 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
> > I'm not suggesting you optimize each statement. I'm suggesting we just
> > leave it to the front end to decide where break/goto elimination (or
> > some other transformation) is appropriate. The front end knows much
> > better when such a transformation is useful.
>
> I disagree. Why would the frontend know better?
Because (in this particular case) the front end knows that it introduces
a goto that can be eliminated without getting into trouble with
overlapping goto's and other unpleasant things. The middle end would
first have to figure that out somehow.
(Of course, one could argue that the front end shouldn't introduce the
goto in the first place...)
> Optimization isn't its job.
I agree, but would you really call this an optimization? I think of it
more as a transformation that allows optimization ;-)
> Do you have a citeseer url for the paper, or a more complete citation?
M. Wolfe, "Optimizing Supercompilers for Supercomputers", Pitman, 1989,
Chapter 10.
> Why wouldn't the middle end want to do these transformations, if
> they're useful? What is special about a FORTRAN DO WHILE loop, as
> opposed to a C while loop?
They're the same, but that's not the point. The point is eliminating
goto's. If you transform all C loops to a loop with a 'goto' to exit the
loop, you'll want to kill that goto at some point, too.
> I don't think saving one walk over the whole tree is worth the loss in
> abstraction.
So do you think we should always do goto/break elimination for GIMPLE
(or GENERIC) then? If so, when and for what constructs should we use it?
In other words: How will the middle end know when these transformations
are useful and not too hard to do?
Think "legacy Fortran 77 code" here, with GOTO's everywhere. Eliminating
all those GOTO's would create way too many "on/off" variables (ref.
simple-goto-elim.c), most of which can probably never be eliminated
during optimization (if there's a lot of overlap for example).
In general, I do not believe that "whole function" goto/break
elimination is a very useful transformation in most cases. Doing the
transformations on big trees is expensive, and sometimes it does more
harm than good.
(ref. http://www.sable.mcgill.ca/~hendren/ftp/erosa/thesis.ps.gz).
Having said that, I guess trying to make loops have regular CFGs is
almost always a good thing. Also, I'm all for abstraction and regular
flow graphs, and I'm not sure what the best solution is...
Greetz
Steven