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: [gomp] OpenMP IL design notes


On Tue, May 03, 2005 at 02:16:35PM -0700, Richard Henderson wrote:
> On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> >   GENERIC
> >   GIMPLE
> >   	GOMP_ATOMIC <expression-statement>
> 
> Do we gain anything over expanding this to the approprate __sync_foo
> builtin in the front end.?
> 
Can the optimizers tell that this is an atomic builtin?  If so,
then no, they're not necessary.

> My intention is to use TLS for this, and to NOT support this feature
> on any system that doesn't support TLS.  Thus this bit is synonymous
> with DECL_THREAD_LOCAL.
> 
OK, good.

> These shouldn't need gimplification.  We should only have decls in
> this list.
> 
That's what I thought at first, but the standard threw me into a
loop when it mentioned "id-expression" instead of just
"identifier" in the C++ case.  If they're essentially the same,
then great.

> > * CLAUSE	default (shared | none)
> > 
> >   GENERIC	This is a boolean field in the GOMP_PARALLEL
> > 		expression.
> > 
> >   GIMPLE	Same.
> 
> IMO this shouldn't escape the front end.  We have different requirements
> for Fortran and C.  We should require that front ends do all symbol
> resolution and provide GENERIC with a complete list of decls.  What 
> reaches GENERIC should be equivalent to default(none) -- that is, all
> variables are either (1) declared inside BIND_EXPRs inside the body of
> the block, or (2) mentioned in one of the relevant variable lists.
> 
OK, that's certainly simpler.


> 	#pragma omp for reduction(+: a, b) reduction(*: c, d)
> 
> I assume the best option would be a list or vector of operator/variable
> pairs.
> 
Yes.  I was only referring to a single instance of reduction.
We'd have to have a vector of those.

> Also note that reduction is also legal on for constructs, and that the
> firstprivate, lastprivate, and copyprivate clauses are legal on other
> work sharing constructs.
> 
Yes, I tried to express that by putting common clauses in
data_clauses and have the various constructs reference it.


Diego.


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