[Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to have incorrect flush example on page 12)
Greg Bronevetsky
greg at bronevetsky.com
Sat May 5 21:24:37 PDT 2007
But its worse. Marcel's example has code like "if(x) {sharedVar=1;}", with
no flushes. gcc performs an optimization that is valid if x ever evaluates
to true because in that case there's a data race. However, this
optimization looks weird if x never evaluates to true because all the code
that was added for the optimization has an effect on the final output. As
such, what we really need is a definition of "data race". Are two accesses
racing if one of them is just in the source code but never actually
executes?
Greg Bronevetsky
On Sat, 5 May 2007, Hoeflinger, Jay P wrote:
> Yes, I think you're right. Likewise, the compiler can't be expected to
> follow control flow. So, the mere existence of a flush without a list
> probably has to put a damper on a lot of otherwise legal optimizations.
> I should go back and look at the gcc optimization that Marcel reported
> (that got this whole discussion started). I'm starting to have my
> doubts that it's really legal.
>
> The spec already gives restrictions on code movement across a flush, and
> also restrictions on holding temporary copies of shared variables across
> a flush. Maybe the area where it's lacking is this issue of what
> "across a flush" means.
>
> We probably should think about this.
>
> Bronis, aren't you in charge of revising the memory model for 3.0? What
> do you think we should do about this?
>
> Jay
>
> -----Original Message-----
> From: Greg Bronevetsky [mailto:greg at bronevetsky.com]
> Sent: Saturday, May 05, 2007 10:46 PM
> To: Hoeflinger, Jay P
> Cc: Yuan Lin; omp at openmp.org
> Subject: RE: [Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to
> have incorrect flush example on page 12)
>
> Yeah, but we're talking about the spec here. We can't specify how
> intelligent a compiler may be. There may be cases where one compiler is
> smart enough to figure out that if(x) will never happen and another is
> not. The spec must account for the full range of compiler intelligence,
> meaning that if(0) must be considered as code that can possibly execute.
>
> Greg Bronevetsky
>
> On Sat, 5 May 2007, Hoeflinger, Jay P wrote:
>
> > This is actually an interesting question, although I would say the
> > compiler could easily remove the target of the IF in the "if(0)" case,
>
> > so it could be certain that the FLUSH would never happen. The
> > problematic case is
> >
> > A=1
> > if(x) { #pragma omp flush }
> > B=2
> >
> > where x is unknowable to the compiler. In this case, I think the
> > compiler must assume that x could be true, since that would cause the
> > most restrictions, and therefore not produce any optimizations that
> > would move code across the flush or carry values across the flush.
> >
> >
> > Jay
> >
> > -----Original Message-----
> > From: omp-bounces at openmp.org [mailto:omp-bounces at openmp.org] On Behalf
>
> > Of Greg Bronevetsky
> > Sent: Saturday, May 05, 2007 8:12 PM
> > To: Yuan Lin
> > Cc: omp at openmp.org
> > Subject: Re: [Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to
> > have incorrect flush example on page 12)
> >
> > I don't think that your examples are fundamentally scary if we think
> > of it as follows. The application contains what looks like a race. In
> > this case the compiler performs a transformation to one of the pieces
> > of code involved in the race. If the race actually happened,
> > everything would be fine because the result would be undefined and the
>
> > transformation would be correct. However, as it turns out, this piece
> > of code is never executed (and so, no race), but the compiler-inserted
>
> > code is still executed, creating a strange result.
> >
> > So here's the question for us: if a given piece of code exists in the
> > source code, does it matter if it is never executed? For example,
> > should the flush in the following code have any effect on possible
> reorderings?
> > A=1
> > if(0) { #pragma omp flush }
> > B=2
> > In the case of a flush, the spec seems to say yes, since it talks
> > about statements in the code, rather than statements that may be
> > executed. In Marcel's example we have code that will not be executed
> > that does not contain a flush. Do we treat it as code that may execute
>
> > and say that the result is undefined because it may be a race or do we
>
> > only worry about races that can happen in actual executions?
> >
> > If we take the former approach, your example 1 would have an undefined
>
> > result, while example 2 would have to print 42. If we take the latter
> > approach, both examples must print 42. I don't know which is better
> > but I don't think the spec addresses this issue.
> >
> > Greg Bronevetsky
> >
> > On Sat, 5 May 2007, Yuan Lin wrote:
> >
> > > Folks, I have no intention to hijack the discussion. But it seems
> > > the following two very basic examples may not work as expected under
>
> > > the current specification.
> > >
> > > S is not volatile.
> > >
> > >
> > >
> > > Example 1
> > > =========
> > >
> > > t1 : t2:
> > >
> > > S = 21;
> > >
> > > barrier 1 barrier 1
> > >
> > > if (some_false_cond) { S = 42;
> > > S = something
> > > }
> > >
> > > barrier 2 barrier 2
> > >
> > > print S;
> > >
> > >
> > > Expectation: t1 always prints out 42.
> > >
> > > But t1 may print out 21, as we previous discovered.
> > >
> > >
> > >
> > > Example 2
> > > =========
> > >
> > > t1 : t2:
> > >
> > > S = 21;
> > >
> > > barrier 1 barrier 1
> > >
> > > S = 42;
> > >
> > > barrier 2 barrier 2
> > >
> > > print S;
> > >
> > >
> > > Expectation: t1 always prints out 42.
> > >
> > > But t1 may print 21 if the compiler inserts code like r = S; S = r;
> > > between the two barriers in thread t1.
> > >
> > > I am not sure about Example 2 (which can be really scary), though
> > > the spec seems to allow the transformation.
> > >
> > >
> > > Regards,
> > >
> > > -- Yuan
> > >
> > > _______________________________________________
> > > Omp mailing list
> > > Omp at openmp.org
> > > http://openmp.org/mailman/listinfo/omp
> > >
> >
> >
> >
> >
> > _______________________________________________
> > Omp mailing list
> > Omp at openmp.org
> > http://openmp.org/mailman/listinfo/omp
> >
> >
>
>
More information about the Omp
mailing list