This is the mail archive of the
mailing list for the GCC project.
Re: [patch, fortran] PR 40628, front-end optimization pass
- From: Thomas Koenig <tkoenig at netcologne dot de>
- To: Daniel Kraft <d at domob dot eu>
- Cc: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sun, 18 Jul 2010 12:17:49 +0200
- Subject: Re: [patch, fortran] PR 40628, front-end optimization pass
- References: <email@example.com> <4C42BF4D.firstname.lastname@example.org>
> 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
> 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