Vaivaswatha Nagaraj via llvm-dev
2015-Dec-04 18:15 UTC
[llvm-dev] RFC: New function attribute HasInaccessibleState
writing into operands is not the same as writing to globals right? I added printf in the same category since we were discussing writing to globals. On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote:>Hi, > >I just want to reiterate: printf and friends do *not* fall into this >category as they can write to their operands (unless you parse and >check >the format string for %n). > >James > >On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> >Most of the time you don't have the entire call graph information. >> Imagine that you are developing a module that is a part of a larger >project. >> I now understand the concern. It looks to me that we will need to set >the >> flag by default to all functions whose definitions aren't available >> (external), and then propagate from there on. I don't see any >optimizations >> being inhibited by such a setting, so it should be okay. >> >> >> >I think we need to go back and look at the underlying use case (as I >> understand it): GlobalAA should be able to figure out that calls to >> malloc/free don't touch global variables visible to the optimizer. >How do >> we address this problem? >> Yes, this is the primary concern. Most libc functions (including >printf, >> malloc, free) fall into the same category. >> >> >> - Vaivaswatha >> >> On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message ----- >>> > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> >>> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >>> > Sent: Friday, December 4, 2015 11:21:03 AM >>> > Subject: Re: [llvm-dev] RFC: New function attribute >>> > HasInaccessibleState >>> >>> > >> In the case of user-defined allocation functions, the >definitions >>> > >> for those functions are available >>> >>> > >Are they? probably not unless you're in an LTO build. >>> >>> > Yes, I'm assuming an LTO build. >>> >>> The concerns around LTO here, while legitimate, apply only to a >>> very-specific kind of LTO: An LTO which includes the definitions of >the >>> libc. This is actually quite tricky to support, semantically, and >already >>> breaks our malloc aliasing assumptions. There are many legitimate >uses of >>> LLVM, both for statically-compiled code and for JIT'd code, that >depend on >>> a visibility boundary between certain core runtime services and the >user >>> code being compiled to provide for effective optimization. >>> >>> So, yes, this will break LTO when you include libc itself in the >>> optimization process. We already don't support this (we'd need, at >least, >>> to adjust our malloc noalias assumptions, if not many other things). >I >>> don't think this is a major concern. >>> >>> I think we need to go back and look at the underlying use case (as I >>> understand it): GlobalAA should be able to figure out that calls to >>> malloc/free don't touch global variables visible to the optimizer. >How do >>> we address this problem? >>> >>> Thanks again, >>> Hal >>> >>> ... >>> >>> > _______________________________________________ >>> > LLVM Developers mailing list >>> > llvm-dev at lists.llvm.org >>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> -- >>> >>> -- >>> Hal Finkel >>> Assistant Computational Scientist >>> Leadership Computing Facility >>> Argonne National Laboratory >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>-- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/764555a0/attachment.html>
James Molloy via llvm-dev
2015-Dec-04 18:17 UTC
[llvm-dev] RFC: New function attribute HasInaccessibleState
It is if one of the operands is or can alias a global ? On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at compilertree.com> wrote:> writing into operands is not the same as writing to globals right? I added > printf in the same category since we were discussing writing to globals. > > On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy < > james at jamesmolloy.co.uk> wrote: >> >> Hi, >> >> I just want to reiterate: printf and friends do *not* fall into this >> category as they can write to their operands (unless you parse and check >> the format string for %n). >> >> James >> >> On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >Most of the time you don't have the entire call graph information. >>> Imagine that you are developing a module that is a part of a larger project. >>> I now understand the concern. It looks to me that we will need to set >>> the flag by default to all functions whose definitions aren't available >>> (external), and then propagate from there on. I don't see any optimizations >>> being inhibited by such a setting, so it should be okay. >>> >>> >>> >I think we need to go back and look at the underlying use case (as I >>> understand it): GlobalAA should be able to figure out that calls to >>> malloc/free don't touch global variables visible to the optimizer. How do >>> we address this problem? >>> Yes, this is the primary concern. Most libc functions (including printf, >>> malloc, free) fall into the same category. >>> >>> >>> - Vaivaswatha >>> >>> On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> ----- Original Message ----- >>>> > From: "Vaivaswatha Nagaraj via llvm-dev" <llvm-dev at lists.llvm.org> >>>> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >>>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >>>> > Sent: Friday, December 4, 2015 11:21:03 AM >>>> > Subject: Re: [llvm-dev] RFC: New function attribute >>>> > HasInaccessibleState >>>> >>>> > >> In the case of user-defined allocation functions, the definitions >>>> > >> for those functions are available >>>> >>>> > >Are they? probably not unless you're in an LTO build. >>>> >>>> > Yes, I'm assuming an LTO build. >>>> >>>> The concerns around LTO here, while legitimate, apply only to a >>>> very-specific kind of LTO: An LTO which includes the definitions of the >>>> libc. This is actually quite tricky to support, semantically, and already >>>> breaks our malloc aliasing assumptions. There are many legitimate uses of >>>> LLVM, both for statically-compiled code and for JIT'd code, that depend on >>>> a visibility boundary between certain core runtime services and the user >>>> code being compiled to provide for effective optimization. >>>> >>>> So, yes, this will break LTO when you include libc itself in the >>>> optimization process. We already don't support this (we'd need, at least, >>>> to adjust our malloc noalias assumptions, if not many other things). I >>>> don't think this is a major concern. >>>> >>>> I think we need to go back and look at the underlying use case (as I >>>> understand it): GlobalAA should be able to figure out that calls to >>>> malloc/free don't touch global variables visible to the optimizer. How do >>>> we address this problem? >>>> >>>> Thanks again, >>>> Hal >>>> >>>> ... >>>> >>>> > _______________________________________________ >>>> > LLVM Developers mailing list >>>> > llvm-dev at lists.llvm.org >>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> -- >>>> >>>> -- >>>> Hal Finkel >>>> Assistant Computational Scientist >>>> Leadership Computing Facility >>>> Argonne National Laboratory >>>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/91b3bacb/attachment.html>
Vaivaswatha Nagaraj via llvm-dev
2015-Dec-04 18:28 UTC
[llvm-dev] RFC: New function attribute HasInaccessibleState
that would be an escaping global, and as far as I know is handled separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global is used as operand to a function) On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy <james at jamesmolloy.co.uk> wrote:>It is if one of the operands is or can alias a global ? >On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <vn at compilertree.com> >wrote: > >> writing into operands is not the same as writing to globals right? I >added >> printf in the same category since we were discussing writing to >globals. >> >> On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy < >> james at jamesmolloy.co.uk> wrote: >>> >>> Hi, >>> >>> I just want to reiterate: printf and friends do *not* fall into this >>> category as they can write to their operands (unless you parse and >check >>> the format string for %n). >>> >>> James >>> >>> On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> >Most of the time you don't have the entire call graph information. >>>> Imagine that you are developing a module that is a part of a larger >project. >>>> I now understand the concern. It looks to me that we will need to >set >>>> the flag by default to all functions whose definitions aren't >available >>>> (external), and then propagate from there on. I don't see any >optimizations >>>> being inhibited by such a setting, so it should be okay. >>>> >>>> >>>> >I think we need to go back and look at the underlying use case (as >I >>>> understand it): GlobalAA should be able to figure out that calls to >>>> malloc/free don't touch global variables visible to the optimizer. >How do >>>> we address this problem? >>>> Yes, this is the primary concern. Most libc functions (including >printf, >>>> malloc, free) fall into the same category. >>>> >>>> >>>> - Vaivaswatha >>>> >>>> On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel <hfinkel at anl.gov> >wrote: >>>> >>>>> ----- Original Message ----- >>>>> > From: "Vaivaswatha Nagaraj via llvm-dev" ><llvm-dev at lists.llvm.org> >>>>> > To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org> >>>>> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> >>>>> > Sent: Friday, December 4, 2015 11:21:03 AM >>>>> > Subject: Re: [llvm-dev] RFC: New function attribute >>>>> > HasInaccessibleState >>>>> >>>>> > >> In the case of user-defined allocation functions, the >definitions >>>>> > >> for those functions are available >>>>> >>>>> > >Are they? probably not unless you're in an LTO build. >>>>> >>>>> > Yes, I'm assuming an LTO build. >>>>> >>>>> The concerns around LTO here, while legitimate, apply only to a >>>>> very-specific kind of LTO: An LTO which includes the definitions >of the >>>>> libc. This is actually quite tricky to support, semantically, and >already >>>>> breaks our malloc aliasing assumptions. There are many legitimate >uses of >>>>> LLVM, both for statically-compiled code and for JIT'd code, that >depend on >>>>> a visibility boundary between certain core runtime services and >the user >>>>> code being compiled to provide for effective optimization. >>>>> >>>>> So, yes, this will break LTO when you include libc itself in the >>>>> optimization process. We already don't support this (we'd need, at >least, >>>>> to adjust our malloc noalias assumptions, if not many other >things). I >>>>> don't think this is a major concern. >>>>> >>>>> I think we need to go back and look at the underlying use case (as >I >>>>> understand it): GlobalAA should be able to figure out that calls >to >>>>> malloc/free don't touch global variables visible to the optimizer. >How do >>>>> we address this problem? >>>>> >>>>> Thanks again, >>>>> Hal >>>>> >>>>> ... >>>>> >>>>> > _______________________________________________ >>>>> > LLVM Developers mailing list >>>>> > llvm-dev at lists.llvm.org >>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>> -- >>>>> >>>>> -- >>>>> Hal Finkel >>>>> Assistant Computational Scientist >>>>> Leadership Computing Facility >>>>> Argonne National Laboratory >>>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >>-- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151204/3981c977/attachment.html>