[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

[Quentin Colombet]

On Oct 22, 2012, at 10:47 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 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...

I agree.
I will eventually go for something like this.

Quentin