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: Vectorising pass (was: Re: SIMPLE)


OOPS, ctrl-ENTER was not the key combination I had in mind. sorry!

Op ma 07-01-2002, om 18:05 schreef Diego Novillo: 
> On Fri, 2002-01-04 at 19:04, Steven Bosscher wrote:
> 
> > 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.
> > 
> Do you have anything specific in mind?  Would this include explicitly
> parallel loops (doall, etc)?  What would be the memory semantics?
>
> We need to give enough information to allow the passes downstream to
> scalarize the expressions (in case it's not worth doing or the target
> doesn't support them or any other reason).

For our purpose, the most interesting aspect of this kind of trees in a
high level GCC IR is the ability of the back end to perform data
dependence analysis. I think this kind of analysis should be in the back
end, not in a front end. On the other hand, GCC apparently does not
support languages with array syntax or explicitly parallel constructs,
so the amounth of work involved could be substantial. Perhaps the best
way to go is to have the front end scalarize the entire parse tree and
hope for the best with GCC's optimalization passes.

Hope this helps, Erik and Andy are physics students and I'm an aerospace
engineering student. We need a computer scientist !!! :-)

I quote here from a mail Erik Schnetter sent me: 

<QUOTE> 
! Yes, I followed the discussion.  I don't have any experience in 
! vectorising.  However, there is a lot of code written without explicit
! vector constructs (say, in C, or in Fortran 77 style), and this code 
! also has to be vectorised.  For that reason I think that it is not 
! necessary to explicitely represent vector operations in the data 
! structure that is passed from the front end to the optimiser.  The 
! back end will have to contain a stage that creates vector 
! expressions from conventional loops. 
! 
! However, that doesn't mean that it wouldn't be convenient to have 
! vector expressions. 
| 
! The basic vector instruction in Fortran is the forall statement.  The 
! forall construct (a multi-line forall block) can easily be translated 
! into several forall statements.  Array operations can also be 
! expressed as forall statements.  Where statements are a syntax for if 
! statements within a forall statement.  If a language independent gcc 
! back end supported these, they would be easier to translate. 
!
! One problem with vector expressions is that their translation might 
! need a temporary vector.  A temporary vector is a temporary array, 
! i.e. an array that is introduced during compilation or optimisation. 
! I don't know whether the gcc back end has support for those. 
! 
! Introducing such an array would be the easy part, but the optimiser 
! would also know when to get rid of temporary arrays -- similar to the 
! stage that currently gets rid of temporary variables. 

I think Erik is right, vector expressions in li-trees is not _necessary_
but it would be _convenient_.  It will probably be hard to implement
anyway.

On memory semantics: If GCC would have a vectorizing pass, GCC should
already be able to guarantee that the vectorized execution of the loop
respects the data dependence relations between the statements in the
loop, and that the semantics of the vectorized loop are preserved.

Is it hard to make sure an already vectorized expression has data
dependance, and scalarize it if it does? How would a vectorizing pass 
work? I couldn't find anything in GCC docs/website about this...

Have a look at this F90 program:

program foo
implicit none

real, dimension (:,:), pointer :: p
real, dimension (6,6), target :: q,r
integer i,j

p => r

! transpose
forall (i=1:6, j=1:6)
  r(i,j) = p(j,i)
end forall

end

Scalarizing this would need a temporary, but if you change a single line:
p => q instead of r, it would not.  In general, it would be very hard for
the Fotran front end to find out when it can do without temporaries. I'm
not sure how good a job GCC would do at eliminating unnecessary temporaries.

In order to completely get rid of analysing data depencence in the
frond end, the back end would need to be able to introduce temporaries
Another sollution may be not to introduce guaranteed concurrency,
potential but potential concurrency, i.e. allow the compiler the freedom
to serialize where it lacks the capabitilies to produce vector code.

So far, there has been little discussion (unlike that other topics
discussed on the gcc mailing list lately ;-) about vector trees in a new
GCC IR. Maybe not everybody is as interested in them, and we should just 
forget about it.

Greetz
Steven


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