On Wed, 1 Feb 2017, Jakub Jelinek wrote:
> IFN_ASAN_POISON is treated that way too. That also means that if a
> variable is previously addressable and the only spot that takes its address
> is that IFN, it can be rewritten into SSA form, but the IFN has to be
> adjusted to something different which no longer takes the address. Perhaps
> for:
>
> > void *simtrec = GOMP_SIMT_ENTER (&var1, &var2, ...);
> >
> > for (...) { ... }
> >
> > var1 ={v} {CLOBBER};
> > var2 ={v} {CLOBBER};
> > ... ;
> > GOMP_SIMT_EXIT (simtrec, &var1, &var2, ...)'
>
> that would just mean dropping that &varN from the two ifns (and the clobbers
> would
> be as usually when rewriting something into SSA get removed).
Ack; thanks.
> That said, I understand how would you add these &varN arguments during
> lowering, but don't understand what would you want to do during inlining,
> if you have addressable vars in inlined function, you need to avoid
> escaping those from the SIMT region.
>
> I believe the abnormal edges turning the SIMT region into kind of loop that
> it to some extent is would take care of this even without having to add
> those addresses to the ifns, but if you don't want to go that way,
> supposedly the inliner would need to find those GOMP_SIMT_* statements
> around the inline caller if any and adjust those?
Yes; I imagine the approach taken in patch 2/5 can be extended to achieve this.
That is, instead of just storing a flag 'bool in_simtreg' in struct loop, store
pointers to corresponding SIMT_ENTER/EXIT gimple statements, use a similar
upwards walk on loop tree to discover if we're inlining into a SIMT region, and
if yes, adjust their argument lists. Does this sound ok?
Alexander
