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

[Jakub Jelinek]

On Thu, Jan 19, 2017 at 04:36:25PM +0300, Alexander Monakov wrote:
> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > Inlining needs to do just like omp-low; if we take the current framework, it
> > > would need to collect addressable locals into one struct, replace references to
> > > those locals by field references in the inlined body.  Then it needs to
> > > appropriately increase allocation size/alignment in SIMT_ENTER() call arguments.
> > > And finally it would need to initialize the pointer to structure, either
> > > immediately after SIMT_ENTER, or in a more fine-grained manner by a
> > > __builtin_alloca_with_align-like function (__b_a_w_a is not usable for that
> > > itself, because currently for known sizes gcc can make it a local variable).
> > 
> > One of the problems with that is that it means that you can't easily turn
> > addressable private variables into non-addressable ones once you force them
> > into such struct that can't be easily SRA split.
> > In contrast, if you can get the variable flags/attributes work, if they
> > become non-addressable (which is especially important to get rid of C++
> > abstraction penalties), you simply don't add them into the specially
> > allocated block.
> 
> I agree; I'd like to implement the approach with per-variable attributes once
> it's clear how it ought to work (right now I'm not sure if placing CLOBBERs on
> both entry and exit would be enough; if I understood correctly, Richard is
> saying they might be moved, unless the middle-end is changed to prevent it).

I think we drop CLOBBERs in certain cases, though primarily those with
MEM_REF on the lhs rather than just VAR_DECL, or even with VAR_DECL in EH
optimizations if the clobbers are the sole thing in the EH pad.
I think adding the abnormal edges would look safest to me, after all, before
it is fully lowered it is kind like a loop, some threads in the warp might
bypass it.  We also use abnormal edges for vfork etc.

> Do you want me to pursue that during the early days of stage 4?  I think it
> would be nice to have the issue addressed in some way for the upcoming release.

Yeah, I'd appreciate if this could be resolved during stage 4, especially if
the changes will have as few changes to the non-GOMP_USE_SIMT paths as
possible.

	Jakub