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>
Troy Johnson via llvm-dev
2018-Aug-17 13:46 UTC
[llvm-dev] alias.scope and local restricted C pointers
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>
Hal Finkel via llvm-dev
2018-Aug-17 16:28 UTC
[llvm-dev] alias.scope and local restricted C pointers
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>