1575198 - Build browser with --enable-cranelift to keep on benchmarking Cranelift

Status: RESOLVED FIXED

(Firefox Build System :: Task Configuration, task)

Description

[Benjamin Bouvier [:bbouvier] (inactive)]

Bug 1555894 has disabled the compilation of Cranelift in Firefox builds by default, unless --enable-cranelift is set in the configure line. This will probably break the AreWeFastYet performance testing of Cranelift, since the about:config pref is likely to be come useless.

The WebAssembly team still wants to measure performance of Cranelift on AWFY, though.

Would it be possible to set up a special build task, that would build the full Firefox browser with --enable-cranelift --enable-release at configure, and then set the pref javascript.options.wasm_cranelift to true? To make it cost-effective for Mozilla, having this task only run once per week would be enough; ideally this would be accompanied by a Perfherder run of the build on the two WebAssembly benchmark suites.

Joel, is this something that sounds feasible? Thanks!

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

having a build on nightly might be ok with the specific jobs running. On that frequency, who will look at the results? The perf sheriffs only look at integration branches. also if there is build breakage, who will fix it?

Comment 2

[Benjamin Bouvier [:bbouvier] (inactive)]

Great, thanks!

If the results are sent to the main AWFY website, we (the WASM team) would take care of checking them; sheriffs shouldn't have to watch these.

Regarding build breakages: if there's a way for us to get notified when the build fails, that would be perfect! We'll then do the right thing according to the kind of build breakage (either fixing it ourselves or pinging the right people). If you need an email list for this, we can start with Lars (cc'd), Julian Seward (:jseward) and me.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

I see wasm-misc and godot as the two benchmarks we run for cranelift:
https://searchfox.org/mozilla-central/search?q=cranelift&path=taskcluster%2Fci

Are these the two?

:egao, could you look into standing up a build variant as outlined above (not a drop everything, but work it in this month if you can). This would be on the nightly scheduler.

Comment 4

[Edwin Takahashi (:egao | infrequent contributor)]

I should be able to get this done before I go on parental leave 9/14.

Comment 5

[Benjamin Bouvier [:bbouvier] (inactive)]

Thanks! (Just confirming Godot and wasm-misc are the two wasm benchmarks we're tracking.)

Comment 6

[Edwin Takahashi (:egao | infrequent contributor)]

:glandium appears to be working on re-enabling cranelift in-tree, so advised me that I hold off for a bit.

While unclear if this is the correct approach, I did get to a point where I defined the tasks and it showed up in Treeherder, albeit not fully building:
https://hg.mozilla.org/try/rev/7fb80150dbe985cd24c9d94c4858f15da63b1079

Comment 7

[Mike Hommey [:glandium]]

With https://github.com/CraneStation/cranelift/pull/924, we should be able to re-enable cranelift at least on automation. That needs an update of cranelift in the tree first though.

Comment 8

[Benjamin Bouvier [:bbouvier] (inactive)]

(In reply to Mike Hommey [:glandium] from comment #7)

With https://github.com/CraneStation/cranelift/pull/924, we should be able to re-enable cranelift at least on automation. That needs an update of cranelift in the tree first though.

Tracked in bug 1576591.

Comment 9

[Mike Hommey [:glandium]]

Attachment: Bug 1575198 - Reenable cranelift on central.

Bug 1555894 disabled it for gecko builds, but since then bug 1576003
and https://github.com/CraneStation/cranelift/pull/924 landed, which
should make its cost to the build less problematic.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/14a789432117
Reenable cranelift on central. r=nalexander

Comment 11

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/14a789432117