<div dir="ltr"><div><div>>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.<br></div>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.<br><br>>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?<br></div>Yes, this is the primary concern. Most libc functions (including printf, malloc, free) fall into the same category.<br><div><div><div><br></div></div></div></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 Fri, Dec 4, 2015 at 11:12 PM, 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: "Vaivaswatha Nagaraj via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><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>
</span><span class="">> Sent: Friday, December 4, 2015 11:21:03 AM<br>
> Subject: Re: [llvm-dev] RFC: New function attribute<br>
> HasInaccessibleState<br>
<br>
</span><span class="">> >> In the case of user-defined allocation functions, the 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>
</span>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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks again,<br>
Hal<br>
<br>
...<br>
<span class=""><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>
</span>--<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div>