[llvm-dev] local restrict - again

[Hal Finkel via llvm-dev]

On 06/28/2018 10:59 AM, Hal Finkel wrote:
> Hi, Jeroen,
>
> We should move these conversations to llvm-dev so that they don't get
> missed and others can contribute. Can I cc the list?

[+llvm-dev] - Jeroen consented.

>
> Doing this will mean that the logic for when to remove dead llvm.noalias
> intrinsics will become more complicated. That might be worthwhile. So
> long as we can answer the basic question:
>
>   Given two memory accesses with the same noalias scope metadata, is one
> pointer derived from a noalias intrinic with the right scope and the
> other not so derived? We don't know this full derivation chain up front,
> and the chain can grow over time (after we do store-to-load forwarding
> in GVN or similar), so we'd need to have something in the pipeline that
> would add this metadata, but this certainly might all be workable.
>
> I think that this is worth exploring.
>
> Thanks again,
>
> Hal
>
>
> On 05/30/2018 09:46 AM, Jeroen Dobbelaere wrote:
>> Hi Hal,
>>
>> we are currently investigating if we can reduce the local restrict issues by making use of a 'side channel'.
>>
>> The rough idea is to start from a base form coming from clang, where we have something like:
>>
>>   ...
>>   %p = ...
>>   %rp =llvm.noalias %p , !scope.., !noalias ...
>>   ...
>>   store %rp, 10, !scope..., !noalias ...
>>   ...
>>
>>
>> and convert it (early, with an llvm-ir pass) to a form like:
>>   ...
>>   %p = ...
>>   %rp =llvm.noalias %p , !scope.., !noalias ...
>>   ...
>>   store %p, 10, !side_gep %rp, !scope..., !noalias ...  //@ Introduction of '!side_gep %rp, and removing the 'direct dependency' on %rp for the store address
>>   ...   
>>
>> This second form, is the version where we can deduce restrictness (through the 'side_gep')
>> We believe that this might help us fix the possible issues with LSR
>> We also think that a variant of this can help us to implement support for a restrict pointer that is member of a struct (and as an extension, for proposal n4150).
>>
>> Do you expect any issue with adding such a 'side channel' metadata to load/store instructions ?
>>
>> Thanks,
>>
>> Jeroen Dobbelaere
>>
>>
>>
>>
>>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory