[LLVMdev] [cfe-dev] RFC: Codifying (but not formalizing) the optimization levels in LLVM and Clang

[Chandler Carruth]

On Mon, Jan 14, 2013 at 11:42 PM, Evan Cheng <evan.cheng at apple.com> wrote:

>
>
> Sent from my iPad
>
> On Jan 14, 2013, at 11:07 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
> On Mon, Jan 14, 2013 at 10:48 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
>>
>>
>> Sent from my iPad
>>
>> On Jan 14, 2013, at 1:09 AM, Chandler Carruth <chandlerc at gmail.com>
>> wrote:
>>
>> > 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.
>> >
>> > 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.
>> >
>> > 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:
>> >
>> >
>> > 1) The easiest: 'Minimize Size' or '-Oz'
>> > - Attribute: minsize (we already have it, nothing to do here)
>> > - Goal: minimize the size of the resulting binary, at (nearly) any cost.
>> >
>> >
>> > 2) Optimize for size or '-Os'
>> > - Attribute: optsize (we already have it, nothing to do here)
>> > - Goal: Optimize the execution of the binary without unreasonably[1]
>> increasing the binary size.
>> > 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.
>>
>> 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.
>>
>
> 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!
>
> Is there something about my proposed wording that makes you think it
> differs from the status quo, or would lead to differences?
>
>
> 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.
>

Heh, I actually deleted a mention of -O2 to avoid a forward reference. How
about this:

2) Optimize for size or '-Os'
- Attribute: optsize (we already have it, nothing to do here)
- Goal: Optimize the execution of the binary without unreasonably[1]
increasing the binary size.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130115/c53ed2de/attachment.html>