<div dir="ltr">No, that'd be redefining the semantics of ReadNone. ReadNone allows elision of a call if its result is unused, which would break some "hasinaccessiblestate" functions (although not malloc).</div><br><div class="gmail_quote"><div dir="ltr">On Fri, 4 Dec 2015 at 09:51 Vaivaswatha Nagaraj <<a href="mailto:vn@compilertree.com">vn@compilertree.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>>but is there or is there not accessible, visible state,<br></div></div><div dir="ltr">Wouldn't ReadNone and/or ReadOnly cover that? If ReadNone is set, it means it doesn't access any of the visible (accessible) states. <br></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"> - Vaivaswatha<br></div></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On Fri, Dec 4, 2015 at 3:17 PM, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I don't think the attribute as is is strong enough to do what you wish. "HasInaccessibleState" is in fact a no-op because it implies nothing about the *accessible* state. OK, there's inaccessible state but is there or is there not accessible, visible state, is the question that optimizers need to ask.</div><div><br></div><div>So I'd rephrase it to something like "HasNoAccessibleState" ?</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Fri, 4 Dec 2015 at 07:58 Vaivaswatha Nagaraj via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div>>is this "internal state” supposed to be private to the function?<br></div></div></div><div dir="ltr"><div>It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state.</div></div><div dir="ltr"><div><br><br>>how this flag would prevent the last “optimization” you’re illustrating<br></div></div><div dir="ltr"><div></div>Assuming you are referring to the quoted examples, currently these optimizations are not happening anyway (from what I understand). The issue is that, after malloc/free are tagged with "ReadNone", such transforms may happen. Hence to prevent that, the additional flag denoting that these functions maintain an internal state. <br><div><br></div></div><div class="gmail_extra"></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"> - Vaivaswatha<br></div></div></div></div><div class="gmail_extra">
<br><div class="gmail_quote">On Fri, Dec 4, 2015 at 12:20 PM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi,<div><br></div><div><div><div><div><blockquote type="cite"><div>On Dec 3, 2015, at 10:33 PM, Vaivaswatha Nagaraj via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div><div>Hi,<br><br></div>This email is in continuation to the mail thread <a href="http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2015-December/092996.html</a>, to propose a new function attribute that can convey that a function maintains state, but this state is inaccessible to the rest of the program under compilation.<br><br></div>Such a flag could be added to most libc/system calls such as printf/malloc/free. (libc and system calls do access/modify internal variables such as errno).<br><div><div><br></div><div>Example attributes (in addition to what are already set):<br></div><div>malloc/free: HasInaccessibleState, ReadNone<br></div><div>printf: HasInaccessibleState, ArgMemOnly<br></div><div>realloc: HasInaccessibleState, ReadOnly (not sure).<br><br></div><div>The intention behind introducing this attribute is to relax the conditions in GlobalsAA as below:<br></div><div>(this code is in GlobalsAAResult::AnalyzeCallGraph)<br></div><div><pre> if (F->isDeclaration()) {
// Try to get mod/ref behaviour from function attributes.
- if (F->doesNotAccessMemory()) {
+ if (F->doesNotAccessMemory() || F->onlyAccessesArgMemory()) {
// Can't do better than that!
} else if (F->onlyReadsMemory()) {
FunctionEffect |= Ref;
if (!F->isIntrinsic())
// This function might call back into the module and read a global -
// consider every global as possibly being read by this function.
FR.MayReadAnyGlobal = true;
} else {
FunctionEffect |= ModRef;
// Can't say anything useful unless it's an intrinsic - they don't
// read or write global variables of the kind considered here.
KnowNothing = !F->isIntrinsic();
}
continue;
}</pre>This relaxation allows functions that (transitively) call library functions (such as printf/malloc) to still maintain and propagate GlobalsAA info. In general, this adds more precision to the description of these functions. <br><br></div><div>Concerns regarding impact on other optimizations (I'm repeating a few examples that Hal mentioned earlier).<br><br>1. <br>><span>A readnone
function is one whose output is a function only of its inputs, and if
you have this:<br>
><br>
> int *x = malloc(4);<br>
> *x = 2;<br>
> int *y = malloc(4);<br>
> *y = 4;<br>
</span><span>> you certainly don't want EarlyCSE to replace the
second call to malloc with the result of the first (which it will
happily do if you mark malloc as readnone).<br><br></span></div><div><span><span><span>For malloc, even though ReadNone is set now (as proposed above), EarlyCSE should be taught to respect the HasInaccessibleState and not combine functions that maintain internal states.</span> <span>Similarly other optimizations (such as DCE) must be taught to respect the flag.</span><br><br>2.<br></span></span><span><span>>void foo(char * restrict s1, char * restrict s2) {<br>
> printf(s1);<br>
> printf(s2);<br>>}<br>
<br>>If printf is argmemonly, then we could interchange the two printf calls.<br><br></span></span></div><div><span><span>In this example too, printf maintains an internal state, preventing the calls from being internchanged</span>. <span>Also, it is now correct to add ArgMemOnly to printf as it does not access any other program memory.</span> <br><br>3.<br></span>>For malloc this is still a problem, in the following sense, if we have:<br>
><br>> p1 = malloc(really_big);<br>> ...<br>> free(p1);<br>
><br>> p2 = malloc(really_big);<br>> ...<br>> free(p2);<br>
>allowing a transformation into:<br>
> p1 = malloc(really_big);<br>> p2 = malloc(really_big);<br>
> ...<br>
> free(p1); free(p2);<br>
>could be problematic.</div><div><span><br></span></div><div><span><span>Both free and malloc would be marked with having an internal state. This should prevent this kind of an optimization</span>. <span>Note that having the ReadNone attribute should not cause problems anymore.</span><br></span></div></div></div></div></blockquote><div><br></div></div></div><div><div>Something is not clear to me: is this "internal state” supposed to be private to the function?</div><div>How does it deal with malloc/free which can be seen as sharing a state? Especially it is not clear to me how this flag would prevent the last “optimization” you’re illustrating.</div><div><br></div><div>— </div><span><font color="#888888"><div>Mehdi</div><div><br></div><div><br><div><blockquote type="cite"></blockquote></div></div></font></span></div></div><br></div></div></blockquote></div><br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
</blockquote></div>
</blockquote></div><br></div></blockquote></div>