Re: [tree-ssa] Use of build_binary_op

[Steven Bosscher <s dot bosscher at student dot tudelft dot nl>]

Op do 26-09-2002, om 12:57 schreef Jason Merrill:
> On 26 Sep 2002 12:06:44 +0200, Steven Bosscher <s.bosscher@student.tudelft.nl> wrote:

> > - a build_gimple_* interface for building GIMPLE stmt trees, that is,
> >   expressions are *not* lowered here.
> > - a gimple_expand_* interface for lowering expressions in GIMPLE trees.
> 
> 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.
 
> Lowering GENERIC to GIMPLE uses simplify_{expr,stmt}.

Hmm yes, I guess that's better.

> 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.
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:

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.

Greetz
Steven