This is the mail archive of the gcc-patches@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: [gomp/rfc] partial reorg of variable remapping


On Sun, Sep 25, 2005 at 02:40:38AM -0700, Richard Henderson wrote:
> So I was looking at the variable remapping stuff, thinking about how
> to implement more than just private, and I notice that things like
> copyin are defined to do the copy-constructor thing in C++.  Which
> means that we really ought to get the front ends to give us ready
> made code sequences for this.
> 
> Which lead me to thinking that the front ends could be managing the
> variable replacement stuff all by themselves.  At least in the case
> of C/C++, this is totally trivial: pushscope/pushdecl/popscope.  It
> has other nice side benefits in that some of the debug things are
> are handled automatically.  Namely, all of the DECLs in question are
> properly attached to a BLOCK.
> 
> Jakub, is this sort of scope management reasonable to do in the 
> Fortran front end?  Or would you have to be creating scope management
> from whole cloth?

There is gfc_namespace, but it has many additional functions beyond
symbol scoping.  Additionally, unlike C/C++, Fortran OpenMP allows
default(private) scope, and symbols used within the omp directive
block can be not only function/subroutine's own variables/dummy arguments,
but also come through host and use association, so creating new variables
for all of them just in case they might be used would be expensive.

That said, as Fortran has its own FE trees that are later on translated into
GENERIC, it is certainly possible to do the remapping in
trans-openmp.c on FE trees right before it is translated into 
GENERIC.

Doing the remapping in the frontends has one additional advantage -
OpenMP standard has different rules for what should be done with
variables not mentioned in either *private nor shared variable lists,
so if the remapping is done during gimplification, we need some language
hook that would decide what to do with each variable.

pushscope/pushdecl/popscope on the C/C++ side will not be enough though
IMHO, for default(none) you need to verify no variables except those on
the lists are mentioned anywhere.

	Jakub


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