1795993 - building FF 106 on x86-32 fails in libwebrtc due to missing -msse2

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Wolfgang Rosenauer [:wolfiR]]

Apparently with the libwebrtc update in bug 1766646 there were also changes in all? moz.build files and at least for x86-32 AND Linux the sections
CXXFLAGS += [
"-msse2"
]
were removed.

I think this is causing my build failures which look like this:
third_party/libwebrtc/modules/audio_processing/aec3/adaptive_fir_filter.cc:110:27: error: always_inline function '_mm_loadu_ps' requires target feature 'sse', but would be inlined into function 'ComputeFrequencyResponse_Sse2' that is compiled without support for 'sse'

There are plenty of similar ones.

Comment 1

[Mike Hommey [:glandium]]

The root of the problem is that we filter flags that come from GN: https://searchfox.org/mozilla-central/rev/7b5c93295ea5071d3cc5b3ac21c6e8e654f69e1b/python/mozbuild/mozbuild/gn_processor.py#329
The list of flags that are kept are defined in https://searchfox.org/mozilla-central/rev/7b5c93295ea5071d3cc5b3ac21c6e8e654f69e1b/dom/media/webrtc/third_party_build/gn-configs/webrtc.json#10-16
which implies we keep -msse2, but what happened is that https://phabricator.services.mozilla.com/differential/changeset/?ref=5242252 switched from -msse2 to -msse3, which we don't keep... OTOH, we wouldn't want -msse3 anyways.

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Mike, could you elaborate on "OTOH, we wouldn't want -msse3 anyways"? Is this because it would exclude older hardware? Would it make sense to add an SSE level flag in the future as we upstream our build changes?

We can test switching back to SSE2 on Elm. https://treeherder.mozilla.org/jobs?repo=try&revision=4376ab82a9b5c3c899012c0e74f65c8743444c3e

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

It seems to generate well on Elm.
Wolfgang, could you try building https://hg.mozilla.org/try/rev/945585ab67de0eb33995a8ded2985ae8c44b360a ?

Comment 4

[Mike Hommey [:glandium]]

Is this because it would exclude older hardware?

Yes. We can't let libwebrtc dictate what we support or not support. We may decide to drop sse2 support in Firefox, but that would be our prerogative. Even if we do, downstreams also may not want to.
Eventually, I'd actually like to leave it to our global flags to handle this, rather than letting some flags through from gn, BUT, it's also more complicated than it seems with some sources that actually require specific flags.

Comment 5

[Nico Grunbaum [:ng, @chew:mozilla.org]]

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

Is this because it would exclude older hardware?

Yes. We can't let libwebrtc dictate what we support or not support.

Agreed.

Comment 6

[Mike Hommey [:glandium]]

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #3)

It seems to generate well on Elm.
Wolfgang, could you try building https://hg.mozilla.org/try/rev/945585ab67de0eb33995a8ded2985ae8c44b360a ?

Note, I did more or less that on Debian, except I didn't change the x64 branch because sse2 is always enabled there in the first place. And it worked.

Comment 7

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1795993 - P0 - revert upstream change from SSE2 to SSE3 in WebRTC;r?glandium,mjf

Comment 8

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1795993 - P1 - regenerate moz.build files;r?glandium,mjf

Depends on D161201

Comment 9

[Mike Hommey [:glandium]]

This would need a refresh and a landing.

Comment 10

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Bug 1795993 - P1 - regenerate moz.build files;r?mjf

Depends on D161201

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66f4374c461f
P0 - revert upstream change from SSE2 to SSE3 in WebRTC;r=mjf
https://hg.mozilla.org/integration/autoland/rev/e0a2047c5471
P1 - regenerate moz.build files;r=mjf

Comment 12

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/66f4374c461f
https://hg.mozilla.org/mozilla-central/rev/e0a2047c5471