[LLVMdev] [RFC] Progress towards OpenMP support

[Sanjoy Das]

Hi Hal,

> My rationale for proposing the self-consistent metadata solution was
> that it seemed to be the safest option. If we simply insist that all
> relevant passes use the ParallizationMetadata pass, without any
> verification, then we could end up with parallelization-unaware passes
> silently miscompiling code when parallelization is enabled. Do you have
> a way of avoiding that?

I'm still not very clear about this.  Either a pass understands (and
looks at) the parallelization metadata or it doesn't.  In case it
doesn't it doesn't matter what the metadata looks like anyway.  In
case it does, we have the ParallelizationMetadata pass to present a
consistent view of the metadata; how does it matter how the metadata
actually looks like?  I think it will be helpful if you could
illustrate your point with an example.

To be clear, I'm not saying that dropping metadata is unreasonable;
but am trying to figure out what the core issues are. :)

> I'm not sure. We do need to make sure, for example, that an 'ordered'
> region stays properly nested within its parent loop.

The ordered region mentions the parent loop anyway.  Since the
grandparent region refs the ordered region, we can ensure that the
ordered region isn't dropped (leading to races).

> We should assert when an individual metadata entry is malformed; we
> should drop non-self-consistent sets of metadata entries (as these
> might have resulted from the actions of non-parallelization-aware
> transformation passes.

Makes sense.

Thanks!
-- 
Sanjoy Das
http://playingwithpointers.com