[Omp] CTOR/DTOR invocation for variables in emptyparalleldirectives?

Hoeflinger, Jay P jay.p.hoeflinger at intel.com
Fri Nov 4 11:41:56 PST 2005


No, I don't assert that the compiler could eliminate a parallel with a
copyin clause.

This is definitely a fuzzy area in the spec.  We are not given enough to
go on in the spec, so we have to fall back to the intent of the text.

The restriction on side effects for clauses was really written to help
maintain serial equivalence.  Any side effects from clauses wouldn't
occur in the serial code, so are prohibited.

Constructors of private variables are of a similar nature because they
represent code that doesn't exist in the serial code, and the function
of the clauses that create private variables doesn't change the global
program state.  So, I believe that the restriction I mentioned applies
to them as well.  

Copyin is a bit different because its *function* is to alter program
state that persists outside the parallel.  So, you could say that no
parallel construct with a copyin has an empty parallel region.

So, no, I wouldn't contend what you say below.  And no, the restriction
doesn't pertain to other directives, just parallel.  That's the only
place it appears in the spec.  

Jay
-----Original Message-----
From: Richard Henderson [mailto:rth at twiddle.net] 
Sent: Thursday, November 03, 2005 3:20 PM
To: Hoeflinger, Jay P
Cc: Diego Novillo; Tian, Xinmin; omp at openmp.org
Subject: Re: [Omp] CTOR/DTOR invocation for variables in
emptyparalleldirectives?

On Thu, Nov 03, 2005 at 08:17:36AM -0800, Hoeflinger, Jay P wrote:
> Because of this, I believe that the compiler is free to dead-code any
> empty parallel region.

So you would contend that

  int x;
  #pragma omp threadprivate(x)

  void broadcast()
  {
  #pragma omp parallel copyin(x)
    ;
  }

Must instead be written

  void broadcast()
  {
  #pragma omp parallel
  #pragma omp single copyprivate(x)
    ;
  }

Or does your contention apply to *all* omp directives, and thus the
only way to correctly write this function is to somehow write a body
that the compiler can't optimize away.


r~




More information about the Omp mailing list