gn: Add an 'optimize' config for components

gn: Add an 'optimize' config for components

The new config can be used by components like v8 or pdfium
to use higher optimization levels on linux and mac.

BUG=chromium:474921, chromium:616031

[Michael Achenbach, 2016-05-30 11:37:40]

Description was changed from

==========
gn: Add an 'optimize' config for components

BUG=
==========

to

==========
gn: Add an 'optimize' config for components

The new config can be used by components like v8 or pdfium
to use higher optimization levels on linux and mac.

BUG=chromium:474921
==========

[Michael Achenbach, 2016-05-30 11:37:40]

machenbach@chromium.org changed reviewers:
+ brettw@chromium.org, dpranke@chromium.org, jochen@chromium.org

[Michael Achenbach, 2016-05-30 11:37:46]

The CQ bit was checked by machenbach@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-30 11:37:55]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2022733002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2022733002/1

[Michael Achenbach, 2016-05-30 11:38:07]

PTAL. This is maybe not final yet. Added a bunch of questions:

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD.gn
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
build/config/compiler/BUILD.gn:1312: config("common_optimize_max") {
Is there a better way to share a common config without making it publicly
available?

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
build/config/compiler/BUILD.gn:1350: configs = [ ":common_optimize_max" ]
Does the line:
configs -= ["optimize_max"]
also remove subconfigs like common_optimize_max?

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
build/config/compiler/BUILD.gn:1359: config("optimize_component") {
Named this optimize_component as I don't like optimize_really_max. Any better
ideas for a name?

[commit-bot: I haz the power, 2016-05-30 12:40:36]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-30 12:40:37]

Dry run: This issue passed the CQ dry run.

[Michael Achenbach, 2016-05-31 10:01:13]

Description was changed from

==========
gn: Add an 'optimize' config for components

The new config can be used by components like v8 or pdfium
to use higher optimization levels on linux and mac.

BUG=chromium:474921
==========

to

==========
gn: Add an 'optimize' config for components

The new config can be used by components like v8 or pdfium
to use higher optimization levels on linux and mac.

BUG=chromium:474921,chromium:616031
==========

[brettw, 2016-05-31 19:26:54]

My preference would be strongly that we have one notion of "higher
optimization" and use that globally. If you notice advantages of using -O3
over -O2, then maybe we should use it everywhere. Are there issues with
this? Maybe we should start a broader thread about this (I don't feel
qualified).

If it turns out we do need different levels, I'd prefer to make "max" be )3
and rename the old one "higher" or something.

Brett

On Mon, May 30, 2016 at 4:38 AM, <machenbach@chromium.org> wrote:

> Reviewers: brettw, Dirk Pranke (slow), jochen (OOO)
> CL: https://codereview.chromium.org/2022733002/
>
> Message:
> PTAL. This is maybe not final yet. Added a bunch of questions:
>
>
>
>
https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD.gn
> File build/config/compiler/BUILD.gn (right):
>
>
>
https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
> build/config/compiler/BUILD.gn:1312: config("common_optimize_max") {
> Is there a better way to share a common config without making it
> publicly available?
>
>
>
https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
> build/config/compiler/BUILD.gn:1350: configs = [ ":common_optimize_max"
> ]
> Does the line:
> configs -= ["optimize_max"]
> also remove subconfigs like common_optimize_max?
>
>
>
https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
> build/config/compiler/BUILD.gn:1359: config("optimize_component") {
> Named this optimize_component as I don't like optimize_really_max. Any
> better ideas for a name?
>
> Description:
> gn: Add an 'optimize' config for components
>
> The new config can be used by components like v8 or pdfium
> to use higher optimization levels on linux and mac.
>
> BUG=chromium:474921
>
> Base URL: https://chromium.googlesource.com/chromium/src.git@master
>
> Affected files (+23, -5 lines):
> M build/config/compiler/BUILD.gn
>
>
> Index: build/config/compiler/BUILD.gn
> diff --git a/build/config/compiler/BUILD.gn
> b/build/config/compiler/BUILD.gn
> index
>
5e1e024ea5ff15eebdb3307d77058d67673073c9..4c32281faba650b5b8856c5ff9632376b2421c5d
> 100644
> --- a/build/config/compiler/BUILD.gn
> +++ b/build/config/compiler/BUILD.gn
> @@ -1308,10 +1308,8 @@ config("no_optimize") {
> }
> }
>
> -# Turns up the optimization level. On Windows, this implies whole program
> -# optimization and link-time code generation which is very expensive and
> should
> -# be used sparingly.
> -config("optimize_max") {
> +# Internal common config used by optimize_max and optimize_component.
> +config("common_optimize_max") {
> if (is_nacl_irt) {
> # The NaCl IRT is a special case and always wants its own config.
> # Various components do:
> @@ -1341,12 +1339,32 @@ config("optimize_max") {
> "/wd4702",
> ]
> }
> - } else {
> + }
> + }
> +}
> +
> +# Turns up the optimization level. On Windows, this implies whole program
> +# optimization and link-time code generation which is very expensive and
> should
> +# be used sparingly.
> +config("optimize_max") {
> + configs = [ ":common_optimize_max" ]
> + if (!is_nacl_irt) {
> + if (!is_win) {
> cflags = [ "-O2" ] + common_optimize_on_cflags
> }
> }
> }
>
> +# Some components like v8 use higher optimization levels on linux and mac.
> +config("optimize_component") {
> + configs = [ ":common_optimize_max" ]
> + if (!is_nacl_irt) {
> + if (!is_win) {
> + cflags = [ "-O3" ] + common_optimize_on_cflags
> + }
> + }
> +}
> +
> # The default optimization applied to all targets. This will be equivalent
> to
> # either "optimize" or "no_optimize", depending on the build flags.
> config("default_optimization") {
>
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Dirk Pranke, 2016-05-31 19:46:18]

In thinking about this further, I think we should probably split out
"optimize_max" from ltcg/wpo/lto. It seems like it makes sense to have some
components optimized as much as possible w/o needing to turn on wpo/ltcg/lto or
whatever you call it.

(and lto is currently separate anyway).

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD.gn
File build/config/compiler/BUILD.gn (right):

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
build/config/compiler/BUILD.gn:1312: config("common_optimize_max") {
On 2016/05/30 11:38:07, Michael Achenbach wrote:
> Is there a better way to share a common config without making it publicly
> available?

Not really, but it's not something we tend to worry about yet.

https://codereview.chromium.org/2022733002/diff/1/build/config/compiler/BUILD...
build/config/compiler/BUILD.gn:1350: configs = [ ":common_optimize_max" ]
On 2016/05/30 11:38:07, Michael Achenbach wrote:
> Does the line:
> configs -= ["optimize_max"]
> also remove subconfigs like common_optimize_max?

Yes, I think so.

[Michael Achenbach, 2016-06-02 09:20:53]

On 2016/05/31 19:26:54, brettw wrote:
> My preference would be strongly that we have one notion of "higher
> optimization" and use that globally. If you notice advantages of using -O3
> over -O2, then maybe we should use it everywhere. Are there issues with
> this? Maybe we should start a broader thread about this (I don't feel
> qualified).

I find this is an orthogonal goal. We could have done this analysis for years,
where we already had different levels of optimization for different components
(using gyp). During the gyp->gn migration, the differences were dropped, which
is a bug that needs fixing.

[Michael Achenbach, 2016-06-02 09:23:35]

> If it turns out we do need different levels, I'd prefer to make "max" be )3
> and rename the old one "higher" or something.

I assume renaming the old one will require a 3-way dance, renaming max in all
the projects that depend on //build. I'd be fine with that if it doesn't
snowball too much.

[Dirk Pranke, 2016-06-02 16:12:48]

On 2016/06/02 09:20:53, Michael Achenbach wrote:
> On 2016/05/31 19:26:54, brettw wrote:
> > My preference would be strongly that we have one notion of "higher
> > optimization" and use that globally. If you notice advantages of using -O3
> > over -O2, then maybe we should use it everywhere. Are there issues with
> > this? Maybe we should start a broader thread about this (I don't feel
> > qualified).
> 
> I find this is an orthogonal goal. We could have done this analysis for years,
> where we already had different levels of optimization for different components
> (using gyp). During the gyp->gn migration, the differences were dropped, which
> is a bug that needs fixing.

We've made a lot of changes during the GYP->GN migration that clean things
up and make them more consistent. I think Brett's suggestion is entirely in line
with that.

I suggest we just change the default and see what happens; if it turns out
to have undesirable effects, then we can create another level.

[brettw, 2016-06-03 21:56:19]

On 2016/06/02 16:12:48, Dirk Pranke wrote:
> On 2016/06/02 09:20:53, Michael Achenbach wrote:
> > On 2016/05/31 19:26:54, brettw wrote:
> > > My preference would be strongly that we have one notion of "higher
> > > optimization" and use that globally. If you notice advantages of using -O3
> > > over -O2, then maybe we should use it everywhere. Are there issues with
> > > this? Maybe we should start a broader thread about this (I don't feel
> > > qualified).
> > 
> > I find this is an orthogonal goal. We could have done this analysis for
years,
> > where we already had different levels of optimization for different
components
> > (using gyp). During the gyp->gn migration, the differences were dropped,
which
> > is a bug that needs fixing.
> 
> We've made a lot of changes during the GYP->GN migration that clean things
> up and make them more consistent. I think Brett's suggestion is entirely in
line
> with that.
> 
> I suggest we just change the default and see what happens; if it turns out
> to have undesirable effects, then we can create another level.

+1, it seems good to me to change the default.

This project is really the "build cleanup" project. One of the main problems
with the build was the tool use to express it. But we've routinely blocked GN
transition progress on fixing it so the right thing happens, and I think this is
desirable. If we don't do it now, we will literally never do it.

[Dirk Pranke, 2016-08-31 23:34:18]

I think we ended up fixing this in a different CL, so I'm closing this one ...