On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> On Wed, Jan 18, 2017 at 05:52:49PM +0300, Alexander Monakov wrote:
> > On Wed, 18 Jan 2017, Jakub Jelinek wrote:
> > > Can't it be e.g. recorded inside a flag on the VAR_DECLs or magic
> > > attributes
> > > on them during omplower time and then only finalized into the magic .local
> > > alloca in the pass_omp_device_lower pass?
> >
> > No (see my adjacent response): it can't be a variable flag because one
> > variable
> > can be private to one SIMD region but not others, and even if we make
> > private
> > instances be separate variables, we need to be sure the compiler can't move
> > references to them outside of their SIMT_ENTER/EXIT SESE region.
>
> If it is a privatized variable in the SIMD region, then it should be used
> only in a single SIMD region and nowhere else (I bet it can appear in the
> initialization or finalization code before/after a SIMD loop), the original
> VAR_DECL/PARM_DECL is replaced during omp lowering with a new VAR_DECL. And
> this happens for each SIMD loop separately. So, if you attach the flag or
> attribute to the replacement VAR_DECL (created through omp_copy_decl_{1,2},
> install_var_local etc.), rather than the original one, I don't see why it
> wouldn't work.
My main concern is that nothing indicates to optimization passes that after
SIMT_EXIT(), underlying storage is unavailable. What would prevent the compiler
from transforming, say
SIMT_ENTER();
// originally omp simd private(inner)
for (...)
{ ... }
outer = inner;
SIMT_EXIT();
into
SIMT_ENTER();
// omp simd private(inner)
for (...)
{ ... }
SIMT_EXIT();
outer = inner; // too late
Also, we'd need to ensure IPA-SRA propagates the magic flag when decomposing
structs.
Alexander
