On Thu, 19 Jan 2017, Richard Biener wrote: > >> 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 > > SIMT_EXIT. > > 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.
Sorry, I don't follow. There is no problem with moving references to data into SIMT regions. The issue is the other way: we need to prevent moving references to data _out_ of SIMT regions -- this is why I said "upwards" across SIMT_ENTER. As far I can tell, my patch does ensure that by performing allocation via IFNs. (and we need to prevent data private to SIMT regions from becoming normal addressable vars on the stack, hence the mention of SRA earlier) Thanks. Alexander
