<div dir="ltr"><div class="gmail_default" style>On Mon, Jan 14, 2013 at 11:42 PM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com" target="_blank" class="cremed">evan.cheng@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="auto">
<div><br><br>Sent from my iPad</div><div><div class="h5"><div><br>On Jan 14, 2013, at 11:07 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank" class="cremed">chandlerc@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div><div dir="ltr"><div>On Mon, Jan 14, 2013 at 10:48 PM, Evan Cheng <span dir="ltr"><<a href="mailto:evan.cheng@apple.com" target="_blank" class="cremed">evan.cheng@apple.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
Sent from my iPad<br>
<div><br>
On Jan 14, 2013, at 1:09 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank" class="cremed">chandlerc@gmail.com</a>> wrote:<br>
<br>
</div><div>> 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.<br>
><br>
> 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.<br>
><br>
> 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:<br>
><br>
><br>
> 1) The easiest: 'Minimize Size' or '-Oz'<br>
> - Attribute: minsize (we already have it, nothing to do here)<br>
> - Goal: minimize the size of the resulting binary, at (nearly) any cost.<br>
><br>
><br>
> 2) Optimize for size or '-Os'<br>
> - Attribute: optsize (we already have it, nothing to do here)<br>
> - Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size.<br>
> 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.<br>
<br>
</div>I'd like to point out that -Os is currently the same level of optimization but with extra attention on code size. It would have significant impact on a lot of clients if we were to change its definition.<br></blockquote>
<div><br></div><div>My intent was not to change the behavior of any of these flags from their current behavior, and mostly to clarify the existing ideas behind them... The most changed / clarified is probably -O3, the rest I think are already working exactly in line with my email... At least, that was my intent!</div>
<div><br></div><div>Is there something about my proposed wording that makes you think it differs from the status quo, or would lead to differences?</div></div></div></div></div></blockquote><div><br></div></div></div>If that's the intention then please make the description explicit. Your description for -Os didn't talk about -O2 so I thought that you are proposing a change.</div>
</blockquote><div><br></div><div style>Heh, I actually deleted a mention of -O2 to avoid a forward reference. How about this:<br><br>2) Optimize for size or '-Os'<br>- Attribute: optsize (we already have it, nothing to do here)<br>
- Goal: Optimize the execution of the binary without unreasonably[1] increasing the binary size.<br>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 normal opt (or -O2) and optsize is that there is an attempt to limit and minimize any growth in the binary size. However, the difference between minsize and optsize levels is more extreme: not only can minsize skip significant optimizations due to even a marginal or minimal binary size change, it is free to *hurt* performance to shrink the size.</div>
</div></div></div>