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]

Vectorising pass (was: Re: SIMPLE)


Hello,

If GCC will have passes that lets "us do higher-level transformations
and anlyses like *vectorisation*, alias analysis, loop optimization,
etc." (see mails below), then why not add generic trees that can
represent vector expressions?

Array syntax is a very important feature in Fortran 9x. It adds more
power to expressions by allowing operations and assignments on arrays or
array sections.  To fully use the potential of Fortran 95, G95 _needs_
trees for vector expressions.

With the proposed SIMPLE gramar, we would first have to scalarize
Fortran expressions.  What a waste, if vectorising pass will be added to
GCC!  I think G95 can generate better code (and compile faster) if we
don't have to scalarize first and then have GCC vectorize stuff again.

There've been discussions about a vectorisation pass in the past, both
on g95-develop and gcc mailing lists.  For example:

http://gcc.gnu.org/ml/gcc/2000-11/msg00662.html.

If such a pass is implemented, I think it would be nice to have li-trees
for vector expressions in a new high-level IR.

Ideas/comments/suggestions/flames? :-)

Greetz
Steven


BTW: Apple people, if you're still interested: the G95 project can use
some help :-)


Op vr 04-01-2002, om 14:22 schreef Diego Novillo:
> On Fri, 04 Jan 2002, Steven Bosscher wrote:
> > We have ld-trees in the form of g95_code and g95_expr structures. Right
> > now we parse complete files into a tree of g95_namespace's, each with
> > its own tree of g95_code. This is similair to function-as-trees. We'll
> > have to generate li-trees from g95_code.
> > 
> Yes.  Once you're ready to do that, maybe you could move your
> work to the ast-optimizer-branch?  I don't know where you folks
> are working, but it might be useful if we all do it out of the
> same code base (if possible).  The ast-optimizer-branch is merged
> periodically with the mainline sources.  It's probably not
> important right now, but we'll need to think about it eventually.
> 
> > > It is also OK if you generate RTL from your function-as-trees as
> > > it is done today in the C-family front-ends.  We can come in
> > > later and wedge the ld-trees lowering phase in between.
> > 
> > Let's first just build trees and worry about RTL later :-)  Let's start
> > with declarations and scalar expressions (and figure out how we can use
> > debug_tree()...)
> > 
> Sounds good.  At this stage we need to exercise the SIMPLE
> grammar with as many front ends as possible.  I'm sure we will
> need to extend it in more than one way.  The goal is to have
> exactly one tree->RTL conversion pass.


Op vr 04-01-2002, om 03:15 schreef Diego Novillo:
> On Fri, 04 Jan 2002, Steven Bosscher wrote:
> 
> > Op wo 02-01-2002, om 13:30 schreef Diego Novillo:
> > > I'm about to start incorporating these things into the AST
> > > branch.  
> > 
> > Does this mean that the decision has been made to go with SIMPLE?
> > 
> Not necessarily.  That's why we'll start working on the AST
> branch.  The hope is that it will be useful and eventually
> incorporated it into mainline.
> 
> We need a lower level tree representation with a number of
> properties to let us do higher-level transformations and anlyses
> like vectorisation, alias analysis, loop optimization, etc.
> SIMPLE is a nice starting point because it was defined on top of
> GCC trees, so the initial implementation is straightforward.  It
> doesn't mean that we will not modify it.


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