On Thu, Jan 19, 2017 at 10:44 AM, Alexander Monakov <[email protected]> wrote:
> 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.
Yes, this way you introduce a data dependence. Doing
SIMT_ENTER (&var, &var2, &var3, &var4...);
would do that as well with the disadvantage of forcing the vars addressable
(thus no SRA, etc.) unless we special-case SIMT_ENTER. If we make sure
to not move clobbers we could also do
SIMT_ENTER ();
var = CLOBBER:
var2 = CLOBBER;
...
The easiest way of ensuring all this is to outline the SIMT region...
(but you've been there...)
> (and we need to prevent data private to SIMT regions from becoming normal
> addressable vars on the stack, hence the mention of SRA earlier)
Richard.
> Thanks.
> Alexander
