This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]