This is the mail archive of the 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: [patch, fortran] PR 40628, front-end optimization pass

Hi Daniel.

> Hi Thomas,
> Thomas Koenig wrote:
> > finally, here's the first attempt at a front-end optimization pass.
> > Right now, it fixes PR 40626 and optimizes comparisons between variables
> > (which only really is relevant for character comparisons).  Many more
> > things could (and should) be added over time.
> thinking about this, I'm not really convinced that we want "front-end 
> optimization passes".  At least for heavier optimization, at least 
> conceptually the middle-end should be responsible.

There are things which are hard for the middle-end to do, especially
character and array expressions.  See, for example, PR 22572 (double
occurrence of matmul not optimized).

> And for smaller ones 
> that are Fortran-specific, we already have the "simplify" code-path.

Simplify is very much geared toward constant simplification.  I made
some attempt at optimization, only to find I would have to modify large
chunks, leading to unnecessary and error-prone changes.

Also, in simplify.c, removing whole statements, adding new variables
etc. is not forseen, also leading to large changes.

Adding a new pass seamed cleaner.  I also wanted the possibility of
making the front-end optimizations

> So 
> what do you think are appropriate use-cases for your new optimization pass?

Things like PR 22572, optimizing expressions like f(x) + f(x) (and warning about
cases where f(x) is non-PURE), optimizing string assignments, PR 30609, ...
A lot of cases where a programmer might be tempted to write "lazy" code
that is currently sub-optimally translated.

> On the other hand, I like the idea of a general high-level 
> pass-framework.  I think that this could help in implementing F2003 
> features (and co), because I'm not sure the current handling during 
> resolution is the best and cleanest (at least not for all constructs). 
> I would have liked to add some construct lowering as seperate passes in 
> the past, so that it does not interfere with real resolution.

That also makes sense.

> What do you (and others) think about introducing your patch as a general 
> pass-framework (and probably not calling it "optimization"), which could 
> then both handle construct implementations as well as certain 
> optimization passes (if it seems reasonable to implement them that way)?

We can use my pass as a starting point, certainly.  Currently, my patch
is run after resolution, but we could certainly set up a general pass
management system.


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