Make gyp tool to emit FDO Support for android.

Make gyp tool to emit FDO Support for android.

To add FDO support for an android static/shared library, one just need to add "LOCAL_FDO_SUPPORT := true" to the library in the mk files. When Android build system sees this flag, it will build the libraries with corresponding FDO flags:

* When built with BUILD_FDO_INSTRUMENT=true, build system will add -fprofile-generate flag to generate instrumented code.
* When built with BUILD_FDO_OPTIMIZE=true, build system will add -fprofile-use flag to generated optimized code.

This patch enables the gyp->mk converting tool to emit correct FDO support to all static libraries in libwebview. It adds an "enable_fdo" variable in the gyp file which tells if the current library needs FDO. If enable_fdo==1, the generated mk file will have FDO enabled.

Additionally, as most of the webview libraries are built with "-Os -finline-limit=64", which contradict with FDO optimization. This patch also added compiler option filtering when FDO is enabled.

BUG=chromium:408567

[dehao, 2014-08-28 14:22:07]

dehao@google.com changed reviewers:
+ torne@chromium.org

[Torne, 2014-08-28 15:20:58]

Can you write a more explanatory CL description that explains what this change
does, why, and what the android build system does when it encounters the
variable?

[dehao, 2014-08-28 15:35:38]

On 2014/08/28 15:20:58, Torne wrote:
> Can you write a more explanatory CL description that explains what this change
> does, why, and what the android build system does when it encounters the
> variable?

Done.

[Torne, 2014-08-28 15:54:56]

gyp-developer people:

What do you think of the approach here? What it's doing is adding a new
target-level setting "android_enable_fdo" which determines whether
feedback-directed optimisation should be on for that target or not.

The reason this is a backend-specific setting is that the Android build system
already implements the entire FDO pipeline as a build option: you enable FDO
data collection or data consumption at the level of the entire system build
(i.e. not just for the gyp-generated projects) and it sets all the flags for
you. This is not really compatible with an approach that does it by just
modifying cflags in the gyp files, since it's a build-time switch, not a
gyp-time one.

I'm not sure I like this very much, but I'm not sure how we could do it better
either. Maybe there should be an android backend equivalent of xcode_settings
that lets you pass fairly arbitrary things directly to the android build system?
Not sure if that's better or worse. :)

Any opinions welcomed...

[Torne, 2014-09-08 17:03:38]

On 2014/08/28 15:54:56, Torne wrote:
> I'm not sure I like this very much, but I'm not sure how we could do it better
> either. Maybe there should be an android backend equivalent of xcode_settings
> that lets you pass fairly arbitrary things directly to the android build
system?
> Not sure if that's better or worse. :)

OK, having thought about this more and gotten some other work on my todo list, I
think it would actually be better to just have an android_settings which let you
set android build system variables directly from the input gyp files. If we had
this then several things that are currently hardcoded in the android generator
could be set in chromium's common.gypi instead, and some of the things I am
planning on adding soon will want to work this way (e.g. setting the SDK level
to compile against: we don't want to hardcode this in gyp).

I'll work on a patch to introduce that feature and once it's done the FDO
support stuff can be done purely in chromium's gyp files, removing the need for
this CL.

[Torne, 2014-09-12 16:45:29]

I'm closing this change as no longer needed. I've landed
https://codereview.chromium.org/565743004/ in gyp and will roll it into chromium
ASAP: https://codereview.chromium.org/568833002/

Once that roll lands we can make the necessary changes in chromium's gyp files
without further changes to gyp.

One note: the variable override support I implemented doesn't handle debug vs
release configurations (seemed too fiddly). I don't think this is actually a
problem; we cannot currently build chromium in debug with the android build
system, it doesn't work at all, so it's fine for LOCAL_FDO_SUPPORT to be enabled
without considering debug/release.