Android LTO caused a 70-90% build time regression (WONTFIX'd bug 1483990). Developers want fast local builds and try runs, so we should disable LTO in non-shipping builds (i.e. non-PGO opt and debug).

Once we have Android PGO builds (bug 632954), we can disable LTO for opt builds. PGO would then imply LTO, like clang-cl did on Windows in bug 1475660.

Would we want to disable LTO for opt builds in all branches (autoland, inbound, central, and try) or just on autoland, inbound, and try? Is there value in building and testing opt with LTO in central in addition to opt without LTO on autoland and inbound? Any bugs we find in one of those configurations but not the other is most likely a compiler bug, not a Firefox bug. Do we care?

(In reply to Chris Peterson [:cpeterson] from comment #0)

Would we want to disable LTO for opt builds in all branches (autoland,
inbound, central, and try) or just on autoland, inbound, and try? Is there
value in building and testing opt with LTO in central in addition to opt
without LTO on autoland and inbound?

I would say that there's anti-value. :) Having different settings based on branch leads to unpleasant surprises, typically in the form of lost developer time in chasing down why something doesn't reproduce in one branch or the other.

Assuming that those PGO+LTO builds get their own full set of tests, I think it would be fine for "opt" to have neither PGO nor LTO on any branch.

LTO was enabled on Android back when the normal Android builds were the
ones we shipped. But now we have separate builds for what is shipped,
and they do PGO+LTO.

https://hg.mozilla.org/mozilla-central/rev/1c3bdc899ec3

== Change summary for alert #24997 (as of Wed, 19 Feb 2020 09:38:27 GMT) ==

Improvements:

63% build times android-5-0-x86_64 asan taskcluster-c5d.4xlarge 2,085.51 -> 763.72

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=24997