Troy Johnson via llvm-dev
2018-Aug-16 20:41 UTC
[llvm-dev] alias.scope and local restricted C pointers
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? 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. Thanks, Troy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180816/856426e5/attachment.html>
Bekket McClane via llvm-dev
2018-Aug-17 00:52 UTC
[llvm-dev] alias.scope and local restricted C pointers
> On Aug 16, 2018, at 4:41 PM, Troy Johnson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Concerning slide 16 of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf <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 <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. 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 <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180816/1f2d64ab/attachment.html>
Hal Finkel via llvm-dev
2018-Aug-17 03:18 UTC
[llvm-dev] alias.scope and local restricted C pointers
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>
Hal Finkel via llvm-dev
2018-Aug-17 03:31 UTC
[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 > 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/8d9d49db/attachment-0001.html>