Allow targets to self-select optimization level in official builds.

With this change, each target can select an optimization level for Windows official builds by setting a variable name "optimize" to one of three possible values:
- "size"; optimizes for minimal code size, the default.
- "speed"; optimizes for speed over code size.
- "max"; turns on link time code generation and whole
   program optimization, which is very expensive and should
   be used sparingly.

Note that this change by itself lowers the optimization level to "size" for all targets. Separate changes to the V8 and WebKit repos will be needed to bring up their optimization levels to WPO. 

BUG=108167
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=115187

[bradn, 2011-12-16 23:44:45]

http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_off...
File build/internal/release_impl_official.gypi (right):

http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_off...
build/internal/release_impl_official.gypi:22: 'VCLinkerTool': {
How about using target_conditions to inject this instead.
'target_defaults': [
  'variables': {
    'performance_critical%': 0,
  },
  'target_conditions': [
    'performance_critical==1', {
      'msvs_settings': {
        'VCCLCompilerTool': {'WholeProgramOptimization': 'true'},
     },
    },
  ],

Then each target can just add:
'performance_critical': 1, to the variable section or each target (or each
target_defaults in a gyp).
Two advantages:
- a clear way to inject into all the targets in a gyp file.
- no specific pathing to an include (allowing us to change things round).

[Sigurður Ásgeirsson, 2011-12-17 04:03:42]

I agree, that's a much better way to do it.
How about calling the variable something like  'optimize', and offering a
choice of e.g. 'size', 'speed', 'all_out', or some such?

On Fri, Dec 16, 2011 at 18:44, <bradnelson@google.com> wrote:

>
> http://codereview.chromium.**org/8983002/diff/1/build/**
>
internal/release_impl_**official.gypi<http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_official.gypi>
> File build/internal/release_impl_**official.gypi (right):
>
> http://codereview.chromium.**org/8983002/diff/1/build/**
>
internal/release_impl_**official.gypi#newcode22<http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_official.gypi#newcode22>
> build/internal/release_impl_**official.gypi:22: 'VCLinkerTool': {
> How about using target_conditions to inject this instead.
> 'target_defaults': [
>  'variables': {
>    'performance_critical%': 0,
>  },
>  'target_conditions': [
>    'performance_critical==1', {
>      'msvs_settings': {
>        'VCCLCompilerTool': {'WholeProgramOptimization': 'true'},
>     },
>    },
>  ],
>
> Then each target can just add:
> 'performance_critical': 1, to the variable section or each target (or
> each target_defaults in a gyp).
> Two advantages:
> - a clear way to inject into all the targets in a gyp file.
> - no specific pathing to an include (allowing us to change things
> round).
>
>
http://codereview.chromium.**org/8983002/<http://codereview.chromium.org/8983...
>

[bradn, 2011-12-17 06:55:21]

SGTM

On Fri, Dec 16, 2011 at 8:03 PM, Sigurður Ásgeirsson <siggi@chromium.org>wrote:

> I agree, that's a much better way to do it.
> How about calling the variable something like  'optimize', and offering a
> choice of e.g. 'size', 'speed', 'all_out', or some such?
>
> On Fri, Dec 16, 2011 at 18:44, <bradnelson@google.com> wrote:
>
>>
>> http://codereview.chromium.**org/8983002/diff/1/build/**
>>
internal/release_impl_**official.gypi<http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_official.gypi>
>> File build/internal/release_impl_**official.gypi (right):
>>
>> http://codereview.chromium.**org/8983002/diff/1/build/**
>>
internal/release_impl_**official.gypi#newcode22<http://codereview.chromium.org/8983002/diff/1/build/internal/release_impl_official.gypi#newcode22>
>> build/internal/release_impl_**official.gypi:22: 'VCLinkerTool': {
>> How about using target_conditions to inject this instead.
>> 'target_defaults': [
>>  'variables': {
>>    'performance_critical%': 0,
>>  },
>>  'target_conditions': [
>>    'performance_critical==1', {
>>      'msvs_settings': {
>>        'VCCLCompilerTool': {'WholeProgramOptimization': 'true'},
>>     },
>>    },
>>  ],
>>
>> Then each target can just add:
>> 'performance_critical': 1, to the variable section or each target (or
>> each target_defaults in a gyp).
>> Two advantages:
>> - a clear way to inject into all the targets in a gyp file.
>> - no specific pathing to an include (allowing us to change things
>> round).
>>
>>
http://codereview.chromium.**org/8983002/<http://codereview.chromium.org/8983...
>>
>
>

[Sigurður Ásgeirsson, 2011-12-20 14:27:26]

With this change, each target can select an optimization level for Windows
official builds by setting a variable name "optimize" to one of three possible
values:
- "size"; optimizes for minimal code size, the default.
- "speed"; optimizes for speed over code size.
- "max"; turns on link time code generation and whole program
    optimization, which is very expensive and should be used
    sparingly.

[Sigurður Ásgeirsson, 2011-12-20 14:40:39]

PTAL

[M-A Ruel, 2011-12-20 14:49:12]

lgtm

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
File build/internal/release_impl_official.gypi (right):

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
build/internal/release_impl_official.gypi:17: '/expectedoutputsize:120000000'
side note: would /expectedoutputsize:160000000 make more sense?

[Sigurður Ásgeirsson, 2011-12-20 15:02:01]

Thanks.

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
File build/internal/release_impl_official.gypi (right):

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
build/internal/release_impl_official.gypi:17: '/expectedoutputsize:120000000'
On 2011/12/20 14:49:12, Marc-Antoine Ruel wrote:
> side note: would /expectedoutputsize:160000000 make more sense?

I don't know, I fear touching these. Feels like "butterfly" programming.

[M-A Ruel, 2011-12-20 15:03:31]

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
File build/internal/release_impl_official.gypi (right):

http://codereview.chromium.org/8983002/diff/4001/build/internal/release_impl_...
build/internal/release_impl_official.gypi:17: '/expectedoutputsize:120000000'
On 2011/12/20 15:02:01, Ruðrugis wrote:
> On 2011/12/20 14:49:12, Marc-Antoine Ruel wrote:
> > side note: would /expectedoutputsize:160000000 make more sense?
> 
> I don't know, I fear touching these. Feels like "butterfly" programming.

Indeed. Don't touch it. :)

[commit-bot: I haz the power, 2011-12-20 15:08:29]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/siggi@chromium.org/8983002/4001

[commit-bot: I haz the power, 2011-12-20 15:09:53]

Try job failure for 8983002-4001 on linux_shared for step "update".
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_shar...

Step "update" is always a major failure.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2011-12-20 16:25:30]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/siggi@chromium.org/8983002/11002

[commit-bot: I haz the power, 2011-12-20 16:27:54]

Try job failure for 8983002-11002 on linux_rel for step "update".
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux_rel&...

Step "update" is always a major failure.
Look at the try server FAQ for more details.

[commit-bot: I haz the power, 2011-12-20 18:13:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/siggi@chromium.org/8983002/10002

[Nico, 2011-12-20 20:03:08]

http://codereview.chromium.org/8983002/diff/10002/build/common.gypi
File build/common.gypi (right):

http://codereview.chromium.org/8983002/diff/10002/build/common.gypi#newcode2511
build/common.gypi:2511: 'optimize%': 'size',
Probably too late, but: Should this be called win_optimize, and should there be
a paragraph saying that this is mostly to work around win linker lto oom? Right
now, this sounds fairly x-plat and I anticipate people changing stuff to
supporting this on mac and linux as well, without any real reason.

[Nico, 2011-12-20 20:03:45]

fff, forgot to uncheck "add as reviewer". removing myself hoping that cq only
checks at commit time

[commit-bot: I haz the power, 2011-12-20 21:37:39]

Change committed as 115187