This should give a few advantages:

• no need to define the defines in several files, it should propagate everywhere
• gives you --enable/--disable configure line options for free, with associated help (we could have --enable-wasm-gc, --enable-wasm-reftypes, etc.)
• build peers will like us more

This got a bit bigger than just wasm (it also includes typed objects now), so updating title.

https://hg.mozilla.org/mozilla-central/rev/86c5f309b369
https://hg.mozilla.org/mozilla-central/rev/424868162298
https://hg.mozilla.org/mozilla-central/rev/2d7295e1d723

== Change summary for alert #19761 (as of Mon, 04 Mar 2019 08:26:52 GMT) ==

Improvements:

11% Base Content JS windows10-64 pgo stylo 5,090,648.00 -> 4,505,718.67
7% Base Content JS windows10-64 pgo stylo 5,092,542.00 -> 4,719,318.67

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

This should not have brought any improvements of some sort, this is weird. (Same thing happened with bug 1527861 which landed in the same batch, where there were improvements on ARM and aarch64)

Trying to understand what's going on here. We were using if CONFIG['NIGHTLY_BUILD'] before, and this has been moved to milestone.is_nightly in moz.configure files.

Nathan, can it happen that these two options are not in sync? (that is, one can be true while the other isn't, or conversely)
If so, then what could have happened is that using milestone.is_nightly is true less often that CONFIG['NIGHTLY_BUILD'] is, which would mean some things got disabled on these builds, making runtime faster (because initialization of JS globals, etc.).

I think what's going on here is that the alert from comment 7 is flagging the wrong bug. If you look at the graph:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=mozilla-inbound,1684832,1,4&zoom=1550066081081.8071,1550422889250.3052,4000000,5309701.492537313

The drop is not related to this code landing; it looks more like bug 1433007 landing (at least if you look at the same metric on autoland, not mozilla-inbound), which makes a lot more sense:

https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=mozilla-inbound,1684832,1,4&series=autoland,1685354,1,4&zoom=1550077437296.7034,1550364217630.0366,4000000,5264925.373134328

The graph does make it look like this bug produced a small blip, which I don't really understand, but at least the big change is easier to understand...?