[PATCH 0/5] OpenMP/PTX: improve correctness in SIMD regions

Jakub Jelinek jakub@redhat.com
Thu Jan 19 09:38:00 GMT 2017

On Thu, Jan 19, 2017 at 10:31:38AM +0100, Richard Biener wrote:
> On Wed, Jan 18, 2017 at 5:22 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
> >> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> >> > We are talking here about addressable vars, right (so if we turn it into
> >> > non-addressable, in the SIMT region we just use the normal PTX pseudos),
> >> > right?  We could emit inner ={v} {CLOBBER}; before SIMT_EXIT() to make it
> >> > clear it shouldn't be moved afterwards.  For the private vars used directly
> >> > in SIMD region, for the vars from inlined functions I assume if they are
> >> > addressable we emit clobbers for them too.  Or perhaps the alias oracle can
> >> > say that SIMT_EXIT ifn can clobber any addressable var with that
> >> > flag/attribute.  And yes, SRA would need to propagate it.
> >>
> >> What about motion in the other direction, upwards across SIMT_ENTER()?
> >
> > I think this is a question for Richard, whether it can be done in the alias
> > oracle.  If yes, it supposedly can be done for both SIMT_ENTER and
> Code motion is trivially avoided for all memory that escapes somewhere.  For
> locals that are just address-taken that's not enough.  So indeed such code
> may move into the SIMT region from both sides -- but that can already happen
> with your proposed patch so it's nothing new.

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?
Then at ompdevlower those would be moved into a struct and from there
onwards they wouldn't be special anymore, just fields in a structure.


More information about the Gcc-patches mailing list