<div dir="ltr"><div><div><div><div>Thanks every one for the inputs so far.<br><br></div>I'll try to summarize some of the key points in the discussion so far.<br><br></div>The new HasInaccessibleState attribute would denote that a function maintains state, but this state is inaccessible to the rest of the program under compilation. In Hal's words, "this function might access globals, but none of these globals are things you can name in the IR being optimized." As Kevin pointed out, "this environmental state is more than just some unaliasable global variables". <br><br></div>If we were to use this attribute, for GlobalsAA to take advantage of the fact that malloc/printf (etc) do not modify program globals, they also need to be marked with ReadNone. As pointed out by James, this might lead to a slight re-definition of the ReadNone attribute, which previously meant that the function does not read any memory, but which would now mean the function does not read any of the program visible memory. So optimizations that rely on ReadNone to transform code may now need to check for HasInaccessibleState too.<br><br></div>Thanks,<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">  - Vaivaswatha<br></div></div></div>
<br><div class="gmail_quote">On Sat, Dec 5, 2015 at 6:02 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Mehdi Amini" <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
</span><div><div class="h5">> Cc: "Vaivaswatha Nagaraj" <<a href="mailto:vn@compilertree.com">vn@compilertree.com</a>>, "LLVM Dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> Sent: Friday, December 4, 2015 12:47:00 PM<br>
> Subject: Re: [llvm-dev] RFC: New function attribute HasInaccessibleState<br>
><br>
><br>
> > On Dec 4, 2015, at 10:33 AM, Hal Finkel via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > ----- Original Message -----<br>
> >> From: "Vaivaswatha Nagaraj" <<a href="mailto:vn@compilertree.com">vn@compilertree.com</a>><br>
> >> To: "James Molloy" <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>>, "Hal Finkel"<br>
> >> <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> >> Cc: "LLVM Dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
> >> Sent: Friday, December 4, 2015 12:28:03 PM<br>
> >> Subject: Re: [llvm-dev] RFC: New function attribute<br>
> >> HasInaccessibleState<br>
> >><br>
> >> that would be an escaping global, and as far as I know is handled<br>
> >> separately in GlobalsAA (AnalyzeUsesOfPointer checks if a global<br>
> >> is<br>
> >> used as operand to a function)<br>
> >><br>
> ><br>
> > More generally, I think this attribute is supposed to mean, "this<br>
> > function might access globals, but none of these globals are<br>
> > things you can name in the IR being optimized." You might, of<br>
> > course, pass in aliasing memory as a parameter, but that's a<br>
> > separate matter.<br>
><br>
> I’m not what "things you can name in the IR” mean exactly, would this<br>
> be equivalent to "none of these globals can alias with any memory<br>
> location accessible from the IR being optimized”?<br>
><br>
> To come back to what I phrased earlier, this effectively split the<br>
> state in two distinct parts, is this enough in all cases? Would<br>
> there be some need/benefit to model more partitions?<br>
<br>
</div></div>I agree this is a good question. I don't have any use cases right now where modeling multiple external states would be useful.<br>
<br>
There might be a relationship to our long-standing problem of modeling errno, but that does not quite fit into this model, because errno is sometimes implemented as a global.<br>
<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks,<br>
><br>
> —<br>
> Mehdi<br>
><br>
> ><br>
> >><br>
> >> On December 4, 2015 11:47:20 PM GMT+05:30, James Molloy<br>
> >> <<a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a>> wrote:<br>
> >><br>
> >> It is if one of the operands is or can alias a global ?<br>
> >><br>
> >><br>
> >> On Fri, 4 Dec 2015 at 18:16, Vaivaswatha Nagaraj <<br>
> >> <a href="mailto:vn@compilertree.com">vn@compilertree.com</a> > wrote:<br>
> >><br>
> >><br>
> >><br>
> >> writing into operands is not the same as writing to globals right?<br>
> >> I<br>
> >> added printf in the same category since we were discussing writing<br>
> >> to globals.<br>
> >><br>
> >><br>
> >><br>
> >> On December 4, 2015 11:34:10 PM GMT+05:30, James Molloy <<br>
> >> <a href="mailto:james@jamesmolloy.co.uk">james@jamesmolloy.co.uk</a> > wrote:<br>
> >><br>
> >><br>
> >> Hi,<br>
> >><br>
> >><br>
> >> I just want to reiterate: printf and friends do *not* fall into<br>
> >> this<br>
> >> category as they can write to their operands (unless you parse and<br>
> >> check the format string for %n).<br>
> >><br>
> >><br>
> >> James<br>
> >><br>
> >><br>
> >> On Fri, 4 Dec 2015 at 17:53 Vaivaswatha Nagaraj via llvm-dev <<br>
> >> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> > wrote:<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >>> Most of the time you don't have the entire call graph<br>
> >>> information.<br>
> >>> Imagine that you are developing a module that is a part of a<br>
> >>> larger<br>
> >>> project.<br>
> >><br>
> >><br>
> >> I now understand the concern. It looks to me that we will need to<br>
> >> set<br>
> >> the flag by default to all functions whose definitions aren't<br>
> >> available (external), and then propagate from there on. I don't<br>
> >> see<br>
> >> any optimizations being inhibited by such a setting, so it should<br>
> >> be<br>
> >> okay.<br>
> >><br>
> >><br>
> >><br>
> >>> I think we need to go back and look at the underlying use case<br>
> >>> (as I<br>
> >>> understand it): GlobalAA should be able to figure out that calls<br>
> >>> to<br>
> >>> malloc/free don't touch global variables visible to the<br>
> >>> optimizer.<br>
> >>> How do we address this problem?<br>
> >><br>
> >><br>
> >> Yes, this is the primary concern. Most libc functions (including<br>
> >> printf, malloc, free) fall into the same category.<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> - Vaivaswatha<br>
> >><br>
> >><br>
> >><br>
> >> On Fri, Dec 4, 2015 at 11:12 PM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> >> wrote:<br>
> >><br>
> >><br>
> >> ----- Original Message -----<br>
> >>> From: "Vaivaswatha Nagaraj via llvm-dev" <<br>
> >>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> >>>><br>
> >>> To: "Krzysztof Parzyszek" < <a href="mailto:kparzysz@codeaurora.org">kparzysz@codeaurora.org</a> ><br>
> >>> Cc: "LLVM Dev" < <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> ><br>
> >>> Sent: Friday, December 4, 2015 11:21:03 AM<br>
> >>> Subject: Re: [llvm-dev] RFC: New function attribute<br>
> >>> HasInaccessibleState<br>
> >><br>
> >>>>> In the case of user-defined allocation functions, the<br>
> >>>>> definitions<br>
> >>>>> for those functions are available<br>
> >><br>
> >>>> Are they? probably not unless you're in an LTO build.<br>
> >><br>
> >>> Yes, I'm assuming an LTO build.<br>
> >><br>
> >> The concerns around LTO here, while legitimate, apply only to a<br>
> >> very-specific kind of LTO: An LTO which includes the definitions<br>
> >> of<br>
> >> the libc. This is actually quite tricky to support, semantically,<br>
> >> and already breaks our malloc aliasing assumptions. There are many<br>
> >> legitimate uses of LLVM, both for statically-compiled code and for<br>
> >> JIT'd code, that depend on a visibility boundary between certain<br>
> >> core runtime services and the user code being compiled to provide<br>
> >> for effective optimization.<br>
> >><br>
> >> So, yes, this will break LTO when you include libc itself in the<br>
> >> optimization process. We already don't support this (we'd need, at<br>
> >> least, to adjust our malloc noalias assumptions, if not many other<br>
> >> things). I don't think this is a major concern.<br>
> >><br>
> >> I think we need to go back and look at the underlying use case (as<br>
> >> I<br>
> >> understand it): GlobalAA should be able to figure out that calls<br>
> >> to<br>
> >> malloc/free don't touch global variables visible to the optimizer.<br>
> >> How do we address this problem?<br>
> >><br>
> >> Thanks again,<br>
> >> Hal<br>
> >><br>
> >> ...<br>
> >><br>
> >>> _______________________________________________<br>
> >>> LLVM Developers mailing list<br>
> >>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> >>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> >><br>
> >> --<br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Hal Finkel<br>
> >> Assistant Computational Scientist<br>
> >> Leadership Computing Facility<br>
> >> Argonne National Laboratory<br>
> >><br>
> >> _______________________________________________<br>
> >> LLVM Developers mailing list<br>
> >> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> >> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> >><br>
> >><br>
> >> --<br>
> >> Sent from my Android device with K-9 Mail. Please excuse my<br>
> >> brevity.<br>
> >> --<br>
> >> Sent from my Android device with K-9 Mail. Please excuse my<br>
> >> brevity.<br>
> ><br>
> > --<br>
> > Hal Finkel<br>
> > Assistant Computational Scientist<br>
> > Leadership Computing Facility<br>
> > Argonne National Laboratory<br>
> > _______________________________________________<br>
> > LLVM Developers mailing list<br>
> > <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>