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