This is the mail archive of the
mailing list for the GCC project.
Re: [patch, fortran] PR 40628, front-end optimization pass
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Daniel Kraft <d at domob dot eu>, Thomas Koenig <tkoenig at netcologne dot de>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Mon, 19 Jul 2010 21:08:03 +0200
- Subject: Re: [patch, fortran] PR 40628, front-end optimization pass
- References: <firstname.lastname@example.org> <4C42BF4D.email@example.com> <4C43D07A.firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Sun, Jul 18, 2010 at 09:11:38PM -0700, Jerry DeLisle wrote:
> On 07/18/2010 01:46 AM, Daniel Kraft wrote:
> >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.
> I like the idea as long as we do not duplicate middle-end work. If
> we can improve performance without sacrificing maintainability and
> correctness, I am all for it. The idea of general passes is good.
> Rather than optimize.c maybe call it early_pass.c or whatever.
What I think would be very useful to do in -fwhole-file mode do a pass
through the front-end trees and improve using that slightly e.g.
dependency.c stuff (unless we jump to middle-end arrays, that's an easy way
to get rid e.g. of unnecessary array temporaries). E.g. in tonto POINTER
vars are ALLOCATED in one routine and not changed afterwards, such vars
could be handled like allocatables.