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
On 26 Sep 2002 13:30:17 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:
> Op do 26-09-2002, om 12:57 schreef Jason Merrill:
>> I'm not sure how you intend these to be used. When would you use
>> build_gimple_* instead of build_*?
> I don't see why the front end would have to know about GENERIC tree
> codes. Lets hide them behind functions, or just #defines.
That's a reason to use build_foo instead of plain build.
>> I don't see any advantage to optimizing each statement as you build it
>> vs. walking the function tree at end-of-function and optimizing loops as
>> you find them. I like the separation of the build and optimization passes.
>>
>> Also, an optimization like that doesn't sound like it belongs in a
>> frontend. I expect there will be some that do, such as operations on
>> FORTRAN arrays (about which I know nothing), but I still think it makes
>> most sense to perform them at end-of-function, perhaps before
>> simplification.
>
> 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? Optimization isn't its
job.
> For example, G95 transforms DO WHILE loops to DO loops with a jump if
> the exit condition is true (as suggested by M. Wolfe, 1989):
>
> DO WHILE (cond1)
> body1
> IF (cond2) CYCLE
> body2
> ...
> END DO
>
> ==>
>
> for ( ; ; )
> {
> pre_cond;
> if (! cond1) goto exit_label;
> body1;
> if (cond2) goto cycle_label;
> body2;
> ...
> cycle_label:
> }
> exit_label:
As it happens, this is the same transformation that I'm doing in
c-simplify.c for C loops; all C loops become an infinite loop with a
conditional goto out. There will be a separate DO_LOOP_EXPR, but that
hasn't been implemented yet.
Do you have a citeseer url for the paper, or a more complete citation?
> For loops like this, the front end should be able to decide that the
> goto's should be eliminated. This is a *local* transformation; no need
> to wait for the whole function body to be optimized.
>
> This way, the middle end will not have to do these transformations,
> which saves you one walk over the whole tree (like we need now for
> goto/break elim.). It also allows the front end to do these
> transformations even if the middle end would never use them.
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?
I don't think saving one walk over the whole tree is worth the loss in
abstraction.
Jason