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.
