[cfe-commits] [PATCH] Oz optimization level sets ForceSizeOpt attribute for each function

[Evan Cheng]

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

> On Mon, Oct 29, 2012 at 1:29 PM, Evan Cheng <evan.cheng at apple.com> wrote:
>> 
>> On Oct 29, 2012, at 1:21 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>>> On Thu, Oct 25, 2012 at 8:46 AM, Quentin Colombet <qcolombet at apple.com> wrote:
>>>> 
>>>> On Oct 24, 2012, at 9:25 PM, Chandler Carruth <chandlerc at google.com> wrote:
>>>> 
>>>>> On Wed, Oct 24, 2012 at 8:58 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Following the adding of the new ForceSizeOpt attribute in LLVM (see commit r1664220), I am making a patch for clang to set this attribute on each function when the Oz optimization level is set.
>>>>> 
>>>>> Can you fix the attribute based on the code review feedback first? I'd
>>>>> rather not start generating the IR when it's about to change.
>>>> 
>>>> Hi Chandler,
>>>> 
>>>> I am not sure to know which review you are talking about.
>>>> From my understanding, according to Eli, it was ok, and according to Evan, it was ok too but may change in the future.
>>>> I was not making the future happening now, if it was that you meant :).
>>>> 
>>> 
>>> This is what he meant, what's the point of doing this as a short term
>>> fix when the full fix is both a) not much more work and b) there are
>>> objections to the existing patch?
>> 
>> It's not a lot of work except for getting agreement. There is no urgency to make the change to -Os[123] now, there are no driving forces behind it. I'd recommend punting it.
>> 
>> As for the attribute name, I have no strong opinions. It's a obviously open to interpretation.
> 
> I think it is important to pick the name well as we'll never be able
> to get rid of it, and the name will inform people's assumptions about
> how it works.
> 
> I don't think we can be lazy about getting the design we want for the
> IR's representation (including the names when they indicate that
> design!) of optimization levels, because we're just going to confuse
> users with mistaken assumptions and expectations. Changing the IR
> isn't easy enough at this point for us to try a few things and see
> what works.

There is no disagreement on coming up with a good name. I just don't think we should tackle the "optimize-for-size-level" part. Ideally it's one attribute with rather than multiple attributes. i.e.

optsize=1
optsize=2
optsize=3

Rather than

optsize
optsizeharder
optsizereallyhard

The former will require significant changes and it is not something we'd want Quentin to tackle at this time.

For the record, -Os / -Oz do not have exact definitions. They are (intentionally?) subject to interpretation by different compilers / targets.

Evan