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

[Troy Johnson via llvm-dev]

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.

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'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.

-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180817/add2df4f/attachment.html>