On Wed, Jan 18, 2017 at 5:22 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Wed, Jan 18, 2017 at 07:15:34PM +0300, Alexander Monakov wrote:
>> On Wed, 18 Jan 2017, Jakub Jelinek wrote:
>> > We are talking here about addressable vars, right (so if we turn it into
>> > non-addressable, in the SIMT region we just use the normal PTX pseudos),
>> > right? We could emit inner ={v} {CLOBBER}; before SIMT_EXIT() to make it
>> > clear it shouldn't be moved afterwards. For the private vars used directly
>> > in SIMD region, for the vars from inlined functions I assume if they are
>> > addressable we emit clobbers for them too. Or perhaps the alias oracle can
>> > say that SIMT_EXIT ifn can clobber any addressable var with that
>> > flag/attribute. And yes, SRA would need to propagate it.
>>
>> 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.
>> > But I believe it is worth it, because inlining is essential for good
>> > performance of the simd regions.
>>
>> It is, but I think my approach is compatible with inlining too (and has a
>> more
>> localized impact on the compiler).
>
> But your 2/5 patch disables inlining into the SIMT regions. Or do you mean
> the approach with some new IFN for the pointers to privatized vars?
> How would that work with the inliner (all copies of addressable vars/params
> from functions inlined into the SIMT region would need to gain something
> similar)?
>
> Jakub
