[Omp] Two simpler examples (Re: OpenMP spec 2.5 seems to have incorrect flush example on page 12)

[Greg Bronevetsky]

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
> 
>