On Thu, 19 Jan 2017, Jakub Jelinek wrote:
> On Thu, Jan 19, 2017 at 10:45:08AM +0100, Richard Biener wrote:
> > > But in the escape analysis we could consider all the specially marked
> > > "omp simt private" addressable vars to escape and thus confine them into 
> > > the
> > > SIMT region that way, right?
> > 
> > We could.  But that doesn't prevent vars from outside of the region to
> > bleed into
> > it which was what Alex was asking about?  For the OMP vars just placing
> > clobbers before EXIT and after ENTER will confine them as well.
> 
> Movement of read accesses to non-"omp simt private" variables into the SIMT
> region across SIMT_ENTER is not a problem I think, those vars still would be
> allocated on the per-warp granularity and all simt threads would just read
> the same value.  The problem would be only if writes to such variables
> are moved later across SIMT_ENTER or earlier across SIMT_EXIT, that would
> turn something initially non-racy into racy.

Hm, I don't share this concern.  You'd still be writing the same value from each
lane, there cannot exist other stores to this variable in the SIMT region
(because otherwise the original OpenMP SIMD code contained a race).  So I cannot
see how this can break program semantics.  Do you mean the formal race of
writing the same value from active lanes?  On PTX that is well-defined, and the
backend already uses that guarantee outside of SIMT regions.

> Would it help if we e.g. have an artificial (ABNORMAL) edge in between basic 
> block with
> SIMT_ENTER and basic block with SIMT_EXIT to make it clearer that those
> calls aren't just ordinary calls, but very special control flow altering
> statements?
> 
>       Jakub

Alexander

Reply via email to