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

[Hal Finkel via llvm-dev]

On 08/16/2018 03:41 PM, Troy Johnson via llvm-dev 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.

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

It could in some cases, and in fact that was my original thought, but
making it work well seems to require a bunch of analysis in the
frontend. The problem is that, in order to conclude that two pointers
don't alias based on restrict, you need to know that one pointer is
based on the restrict-qualified pointer and the other, within the
appropriate scope, is not. Doing this relies on data-flow and aliasing
analysis (which would need to be pretty simple in the frontend), but
also becomes pessimistic when pointers are passed to functions (because
they might be captured). Especially in C++ (where restrict is often used
as an extension), the function-call-capturing problem can be significant
because all of the overloaded operators are function calls (and so on).
When we have restrict on function parameters we add noalias on the LLVM
IR level to those parameters, and if we later inline that function, we
add this noalias metadata, but at that point, we've already done IPO
nocapture inference, memory-to-register conversation, and have access to
LLVM's AA infrastructure.

I'd proposed an llvm.noalias intrinsic in order to address this problem
(and the patches for this, including frontend patches, are on
phabricator). Originally, I had wanted to make the intrinsic fairly
transparent, such that it would have minimal interference on other
optimizations. Part of the problem is that I wanted to intrinsic to fix
itself to a particular place in the CFG in order to be able to
differentiate, as a particular design point, between noalias pointers
within one loop iteration vs. across all loop iterations (based on
whether the intrinsic was inside or outside the loop). This means that
the intrinsic had to be annotated such that it could not be hoisted. In
any case, after testing, we found problems with the transparency of the
intrinsic because, both literally and effectively during the recursive
AA-query-processing algorithm, we could break the dependence of a
pointer value on the intrinsic from which it was originally derived.
This can't happen and have the scheme maintain correctness. Thus, we
need to make it hard for analysis to look through the intrinsic, and
thus it even has a larger impact on other optimizations. Several people
have been thinking about this problem, but I wouldn't say that we yet
have a clearly-good answer yet. Maybe we want to start with the
intrinsic and then translate it later into maetadata, for example.

 -Hal

>  
>
> Thanks,
>
> Troy
>
>  
>
>  
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> 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/20180816/ca7c2cf1/attachment.html>