Re: [PATCH] x86: Set optimize to INT_MAX for -Os

[Paul Koning <paulkoning at comcast dot net>]

> On Mar 19, 2019, at 4:07 AM, Jan Beulich <JBeulich@suse.com> wrote:
> 
>>>> On 19.03.19 at 02:43, <hjl.tools@gmail.com> wrote:
>> On Mon, Mar 18, 2019 at 7:35 PM Jan Beulich <JBeulich@suse.com> wrote:
>>> 
>>>>>> On 17.03.19 at 00:50, <hjl.tools@gmail.com> wrote:
>>>> Set optimize to INT_MAX, instead of -1, for -Os so that -Os will include
>>>> -O2 optimization.
>>> 
>>> I didn't think -Os should be a superset of -O2. Iirc it's not for e.g.
>>> gcc. Why would this be a good idea? Judging by the PR it should
>>> rather be the doc to get changed imo.
>> 
>> -Os was designed to include -O2.
> 
> Well, taking compilers for comparison, -O<number> typically implies
> optimization for performance. This often is requiring different
> adjustments to generated code than size optimizations. I understand
> (from the doc fragment) that it was meant to be that way; I wonder
> though whether this shouldn't be re-considered (and to be honest,
> back when you had introduced it, I merely looked at code and hence
> didn't realize that code - matching my expectations - wasn't in line
> with the doc).

Agreed.  It's certainly not the case that -Os is a superset of -O2, and if it were that would be a serious bug.  For example (in gcc) -O2 does loop unrolling, which in general -Os should not do.  Also, quite apart from specific detail optimizations, -Os also affects internals like the cost calculation in the back end.  The documentation states that the intent is for the cost function to return a number measuring execution time for -O<number>, but a number relating to code size for -Os.  And indeed at least some of the back ends implement this.

	paul