[llvm-dev] alias.scope and local restricted C pointers

[Hal Finkel via llvm-dev]

On 08/17/2018 08:46 AM, Troy Johnson wrote:
> Thanks to both of you for clarifying.
>
> Bekket, local restrict is pretty common in my experience, at least
> with our users.  It would be good for it to work as expected.
>
> Hal, I appreciate the difficulty in doing the based-on analysis, but
> it needs to be understood that a C compiler was never really expected
> to do that analysis!  Being able to do it would be great, of course,
> but it is quite daunting and was not the original intent of restrict. 
> I have in fact worked with the original author of the restrict keyword
> and proposed WG14/N2260 to clarify its usage and intent.
>
> Basically, the based-on terminology was the least bad way anyone
> thought of at the time to describe the semantics.  The belief was that
> users would supply restrict on multiple pointers of the same type
> whenever none of them aliased, then use those pointers directly. 
> Doing the based-on analysis is similar to what's required to usefully
> interpret a single restrict-qualified pointer in isolation, and that's
> considered unreasonably hard.

You're proposing that there is some common cases, dealing specifically
with multiple restrict pointers, where the based-on relationship is
clear, and handling those using the existing metadata. I'm not sure how
limiting this would be, but certainly could be worth doing. We should
discuss this in more detail.

>
> So I think this problem is quite solvable in the common (and
> recommended) case of the user specifying restrict liberally and
> accessing data directly via those pointers.
>
> The use case that I normally see is a bunch of local restricted
> pointers initialized once and indexed by some increasing integer.  The
> compiler would honor restrict if the user outlined the code into a
> separate function and the pointers were parameters instead.  Sometimes
> that is the recommended workaround, but it shouldn't be necessary.

I agree. I'd like this workaround not to be necessary.

>
> I'm happy to discuss futher with whomever works on the related parts
> of Clang and LLVM.  I am not familiar with who that might be.

I did most of the work associated with the llvm.noalias metadata and the
proposed llvm.noalias patches. Others have been investigating this as
well. I'm happy to discuss this with you (and, unless there's some
reason to do otherwise, we can discuss this here, for LLVM issues, or on
cfe-dev, for issues of how Clang translates C into LLVM).

Thanks again,
Hal

>
> -Troy
> ------------------------------------------------------------------------
> *From:* Hal Finkel <hfinkel at anl.gov>
> *Sent:* Thursday, August 16, 2018 10:31:52 PM
> *To:* Bekket McClane; Troy Johnson
> *Cc:* llvm-dev at lists.llvm.org
> *Subject:* Re: [llvm-dev] alias.scope and local restricted C pointers
>  
>
> On 08/16/2018 07:52 PM, Bekket McClane via llvm-dev wrote:
>>
>>
>>> On Aug 16, 2018, at 4:41 PM, Troy Johnson via llvm-dev
>>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>>
>>> Concerning slide 16
>>> of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf
>>>  
>>> Specifically “Currently, LLVM only supports restrict on function
>>> arguments, although we have a way to preserve that information if
>>> the function is inlined.”
>>>  
>>> Is that statement still accurate? 
>>
>> Yes, correct (actually I was just working on restrict, no_alias and
>> alias.scope attributes). The inliner also propagates them correctly. 
>>
>>> It would seem
>>> that https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata should
>>> be sufficiently general to honor C’s restrict qualifier on local
>>> pointers,
>>> but it does not appear that Clang uses this part of LLVM’s IR for
>>> that purpose today and thus local restricts are ignored.
>>
>> I think that’s correct, but I haven’t come out with any scenarios
>> regarding local variables/memory that can _not_ be solved by AA. As
>> BasicAA is able to solved most of the local cases, including malloc
>> and some memory intrinsics.
>
> int *restrict x = some_external_function();
> int *restrict y = some_other_external_function();
>
> This is one of the fundamental use cases for restrict and BasicAA has
> nothing to offer in this regard. In other words, it's a mechanism for
> encoding an interface contract.
>
>  -Hal
>
>>
>> Best
>> Bekket
>>>  
>>> Thanks,
>>> Troy
>>>  
>>>  
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180817/50f916af/attachment.html>