[llvm-commits] [llvm] r166422 - in /llvm/trunk: include/llvm/Attributes.h lib/AsmParser/LLLexer.cpp lib/AsmParser/LLParser.cpp lib/AsmParser/LLToken.h lib/VMCore/Attributes.cpp

[Chandler Carruth]

On Mon, Oct 22, 2012 at 10:24 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>
>
> On Oct 22, 2012, at 12:56 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
>> On Mon, Oct 22, 2012 at 10:33 AM, Nadav Rotem <nrotem at apple.com> wrote:
>>> Author: nadav
>>> Date: Mon Oct 22 12:33:31 2012
>>> New Revision: 166422
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=166422&view=rev
>>> Log:
>>> Add the "ForceSizeOpt" attribute.
>>>
>>> Patch by Quentin Colombet <qcolombet at apple.com>
>>>
>>> Original description:
>>> """
>>> The attached patch is the first step to have a better control on Oz related optimizations.
>>> The Oz optimization level focuses on code size, thus I propose to add an attribute called ForceSizeOpt.
>>> """
>>
>> So, Quentin, sorry I didn't see your original email, but I think
>> ForceSizeOpt is the wrong name here.
>>
>> -Oz isn't about *forcing* the size-opt use case. It doesn't override
>> anything, etc. It's about how we optimize for size.
>>
>> -Os --> When we could get performance at a significant cost to size,
>> don't go after that performance. That said, don't actively degrade
>> performance just to get size.
>> -Oz --> Actively degrade performance to shrink the code.
>>
>> The important difference is that -Os should not really make code any
>> slower than -O0 or even -O1. On the other hand -Oz might actively slow
>> code down, and do other crazy things just to achieve a size reduction.
>>
>
> My read of -Os is optimize for speed is priority 1, code size 2. -Oz is code size 1, speed 2. I think saying -Oz would intentionally generate slower code for the sake of code size is going a bit too far.

While I don't necessarily disagree here (the exact degree to which -Oz
optimizes isn't a terribly clear or fixed thing) ...

> So I think the name kinda makes sense in this context.

I don't really follow here. "Force" implies some overriding of another
decision. -Oz doesn't seem any more or less forced than -Os. For
example, if we were to have a function attribute to indicate -O3 level
of optimizations on a function (which I realize we don't), the name
select here might seem to indicate it should be preferred over the
attribute, but I don't see why -Oz would cause that interpretation any
more or less than -Os.

This type of interpretation of 'Force' would be more consistent with
the various flag structures in Clang at least...

> It's at least better than Chris' OptSizeHarder.

Sure, but I think we can do something that actually models the semantics here.

> The right solution might be something like -Os[123] if anyone wants to start doing some really aggressive code size optimization.

Yea, if we ever get there, that would make much more sense.

It might be reasonable to just design the internal flag this way, and
map -Oz to OptSizeLevel=2 or some such...