<div dir="ltr"><div>If I understand the attributes correctly, they would be function-level attributes applied to IR functions, correct? I'm curious what the semantics would be for cross-function optimization. For example, consider a function "foo" defined with maxopt and a function "bar" defined with optsize. If foo() calls bar() and the inliner wants to inline bar() into foo(), is that legal? If so, that may cause odd effects as you may perform expensive optimizations later on the inlined version of bar(), even though the original function is marked optsize.<br>
<br></div>Also, a nit-pick: can we make the naming consistent? It feels a bit weird to have maxOPT and OPTsize. Perhaps use sizeopt and minsizeopt, or optmax and optquick?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 14, 2013 at 4:09 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</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"><div class="gmail_default">This has been an idea floating around in my head for a while and after several discussions with others it continues to hold up so I thought I would mail it out. Sorry for cross posting to both lists, but this is an issue that would significantly impact both LLVM and Clang.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Essentially, LLVM provides canned optimization "levels" for frontends to re-use. This is nothing new. However, we don't have good names for them, we don't expose them at the IR level, and we have a hard time figuring out which optimizations belong in which levels. I'd like to try addressing that by coming up with names and a description of the basic intend goal of each level. I would like, if folks are happy with these ideas, to add these types of descriptions along side these attributes to the langref. Ideas on other (better?) places to document this would be welcome. Certainly, Clang's documentation would need to be updated to reflect this.</div>
<div class="gmail_default"><br></div><div class="gmail_default">Hopefully we can minimally debate this until the bikeshed is a tolerable shade. Note that I'm absolutely biased based on the behavior of Clang and GCC with these optimization levels, and the relevant history there. However, I'm adding and deviating from the purely historical differences to try and better model the latest developments in LLVM's optimizer... So here goes:</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">1) The easiest: 'Minimize Size' or '-Oz'</div><div class="gmail_default">- Attribute: minsize (we already have it, nothing to do here)<br>
</div><div class="gmail_default">- Goal: minimize the size of the resulting binary, at (nearly) any cost.</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">
2) Optimize for size or '-Os'</div><div class="gmail_default">- Attribute: optsize (we already have it, nothing to do here)</div><div class="gmail_default">- Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size.</div>
<div class="gmail_default">This one is a bit fuzzy, but usually people don't have a hard time figuring out where the line is. The primary difference between minsize and optsize is that with minsize a pass is free to *hurt* performance to shrink the size.</div>
<div class="gmail_default"><br></div><div class="gmail_default">[1] The definition of 'unreasonable' is of course subjective, but here is at least one strong indicator: any code size growth which is inherently *speculative* (that is, there isn't a known, demonstrable performance benefit, but rather it is "often" or "maybe" a benefit) is unlikely to be a good fit in optsize. The canonical example IMO is a vectorizer -- while it is reasonable to vectorize a loop, if the vector version might not be executed, and thus the scalar loop remains as well, then it is a poor fit for optsize.</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">3) Optimize quickly or '-O1'</div><div class="gmail_default">- Attribute: quickopt (this would be a new attribute)</div>
<div class="gmail_default">- Goal: Perform basic optimizations to improve both performance and simplicity of the code, but perform them *quickly*.</div><div class="gmail_default">This level is all about compile time, but in a holistic sense. It tries to perform basic optimizations to get reasonably efficient code, and get it very quickly.</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">4) Good, well-balanced optimizations, or '-O2'</div><div class="gmail_default">- Attribute: opt (new attribute)</div>
<div class="gmail_default">- Goal: produce a well optimized binary trading off compile time, space, and runtime efficiency.</div><div class="gmail_default">This should be an excellent default for general purpose programs. The idea is to do as much optimization as we can, in as reasonable of a time frame, and with as reasonable code size impact as possible. This level should always produce binaries at least as fast as optsize, but they might be both bigger and faster. This level should always produce binaries at least as fast as quickopt, but they might be both slower to compile.</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">5) Optimize to the max or '-O3'</div><div class="gmail_default">- Attribute: maxopt (new attribute)</div>
<div class="gmail_default">- Goal: produce the fastest binary possible.</div><div class="gmail_default">This level has historically been almost exclusively about trading off more binary size for speed than '-O2', but I would propose we change it to be more about trading off either binary size or compilation time to achieve a better performing binary. This level should always produce binaries at least as fast as opt, but they might be faster at the cost of them being larger and taking more time to compile. This would in some cases be a change for LLVM and is definitely a deviation from GCC where O3 will in many cases produce *slower* binaries due to code size increases that are not accompanied by corresponding performance increases.</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">To go with these LLVM attributes I'd like to add support for adding attributes in Clang, both compatible with GCC and with the names above for clarity. The goal being to allow a specific function to have its optimization level overridden from the command line based level.</div>
<div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default">A final note: I would like to remove all other variations on the '-O' flag. That includes the really strange '-O4' behavior. Whether the compilation is LTO should be an orthogonal decision to the particular level of optimization, and we have -flto to achieve this.</div>
<span class="HOEnZb"><font color="#888888">
<div class="gmail_default"><br></div><div class="gmail_default">-Chandler</div></font></span></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><br><div>Thanks,</div><div><br></div><div>Justin Holewinski</div>
</div>