Per https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/TivwVmhWOQAJ it's now OK to require SSE2 for Mozilla-made builds of Firefox for Linux x86. Therefore, the build config for Mozilla-official builds as well as the default build config (so that people develop with settings that match the shipping config) should be changed to target SSE2 (i.e. turn on SSE2-based IEEE-compliant floating point math and turn on SSE2 autovectorization).

(In reply to Henri Sivonen (:hsivonen) from comment #0) > Per > https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/ > TivwVmhWOQAJ it's now OK to require SSE2 for Mozilla-made builds of Firefox > for Linux x86. > > Therefore, the build config for Mozilla-official builds as well as the > default build config (so that people develop with settings that match the > shipping config) should be changed to target SSE2 (i.e. turn on SSE2-based > IEEE-compliant floating point math and turn on SSE2 autovectorization). I'm conflicted on this... On one end I can understand the point of doing so, on the other hand, it might make it painful for people who want to explicitly build with even higher (or lower) standards. (It's typical of Gentoo users to build targetting their specific CPU type). That being said, the typical options for SSE2 are only likely to be a problem for explicit builds with lower standards (for example, -mavx2 -msse2 is equivalent to -msse2 -mavc2 is equivalent to -mavx2). With all that being said, people already don't develop with settings that match the shipping config, which does PGO, so it's not really a compelling argument anyways. And most people are doing x86-64 builds anyways. The more compelling argument is that what distros ship would be more different from what Mozilla ships. OTOH, there might be reasons for their compiler not defaulting to SSE2 enabled by default. For instance, both Ubuntu and Debian don't have GCC defaulting to SSE2 (or SSE for that matter). I don't know what the explicit choice is for Ubuntu, but for Debian, it's definitely an explicit choice that SSE is not enabled by default. I don't know about Fedora or other distros. Anyways, all that to say that it's way too early IMHO to make a decision for them, so for now at least, I'd stick with modifying our mozconfigs and nothing else. We'll want -msse2 -mfpmath=sse to replace -march=pentiumpro. Autovectorization is an optimization pass that is enabled at -O3. Our default is to build the js engine at -O3 and gecko at -Os, except on PGO builds, which use -O3 (with GCC then tweaking optimizations levels on cold code ; presumably that means it can disable autovectorization on cold code). I'd say we don't need to explicitly enable autovectorization. I wouldn't be surprised if the switch of floating point type breaks things like some reftests. So, I'd suggest a try push, too.

(In reply to Mike Hommey [:glandium] from comment #1) > Anyways, all that to say that it's way too early IMHO to make a decision for > them, so for now at least, I'd stick with modifying our mozconfigs and > nothing else. In https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/3Gj84sKKOQAJ you said that distros compiling Rust with non-default instruction set options is there concern and not mine. Why would it be different for C++? If Mozilla ships with targeting SSE2, it seems to me that the configuration you get with vanilla mozconfig (i.e. the config that developers are likely to use) should be SSE2 and if a distro wants to do something different, modifying the mozconfig should be done at their end. If developers not editing mozconfig leads them to build with different floating point math than releases, it seems like a way to waste time debugging e.g. graphics reftest problems.

There is a difference between following whatever the compiler defaults to, and actively going against them. Enabling SSE2 on GCC is the latter, and doing that for everyone removes opportunities for customization. It's not a matter of "modifying a mozconfig". For one, the mozconfigs we have in-tree are for Mozilla automation only. They contain things very specific to Mozilla automation, and are not suitable for use by third parties. And defaults in configure are difficult to override, so that needs to be well thought out. And doesn't need to block Mozilla from shipping SSE2-enabled builds. They are orthogonal issues. If we want to go full steam on SSE2 and force it, then it's yet another issue, with a different implementation, and that decision hasn't been reached anyways. Finally, "developers" are already not using the same compiler and compiler options as Mozilla-released builds. And I doubt a lot of them are actually building x86 binaries. I'm not particularly concerned that they wouldn't get the same as Mozilla-released builds out of the box for some time between Mozilla-released builds opting-in to SSE2 and the build system catching up with properly overridable defaults.

(In reply to Mike Hommey [:glandium] from comment #3) > And I doubt a lot of them are actually building x86 binaries. *Linux* x86 binaries.

(In reply to Mike Hommey [:glandium] from comment #1) > (In reply to Henri Sivonen (:hsivonen) from comment #0) > > Per > > https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/ > > TivwVmhWOQAJ it's now OK to require SSE2 for Mozilla-made builds of Firefox > > for Linux x86. > > > > Therefore, the build config for Mozilla-official builds as well as the > > default build config (so that people develop with settings that match the > > shipping config) should be changed to target SSE2 (i.e. turn on SSE2-based > > IEEE-compliant floating point math and turn on SSE2 autovectorization). > > The more compelling argument is that what distros ship would be more > different from what Mozilla ships. OTOH, there might be reasons for their > compiler not defaulting to SSE2 enabled by default. For instance, both > Ubuntu and Debian don't have GCC defaulting to SSE2 (or SSE for that > matter). I don't know what the explicit choice is for Ubuntu, but for > Debian, it's definitely an explicit choice that SSE is not enabled by > default. I don't know about Fedora or other distros. I'm pretty sure that the real reason of the distros for doing this is, that Linux/this distros are perfect to "recycle" old machines e.g. as gateways, proxies, print-server, ... and "stupid machines" that do things like grid computing, pinging, brute force, etc. ... As described in https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0 there is really no logical reason to use FF in a real non-SSE2 environment! I be also petty sure that no one will really recognize or miss it and this was also the reason why I suggested a error msg in the next build to see if really someone cares about it and if, if he fix it on his side (e.g. turn SSE2-Support on in BIOS or set up a other machine), or if someone is really disappointed about it and brings any real reason (a situation that don't exist only theoretical) to change the decisions and plans of Mozilla. (In reply to Henri Sivonen (:hsivonen) from comment #2) > (In reply to Mike Hommey [:glandium] from comment #1) > > Anyways, all that to say that it's way too early IMHO to make a decision for > > them, so for now at least, I'd stick with modifying our mozconfigs and > > nothing else. > > In > https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/ > 3Gj84sKKOQAJ you said that distros compiling Rust with non-default > instruction set options is there concern and not mine. Why would it be > different for C++? > > If Mozilla ships with targeting SSE2, it seems to me that the configuration > you get with vanilla mozconfig (i.e. the config that developers are likely > to use) should be SSE2 and if a distro wants to do something different, > modifying the mozconfig should be done at their end. > > If developers not editing mozconfig leads them to build with different > floating point math than releases, it seems like a way to waste time > debugging e.g. graphics reftest problems. I'm involved in application development but normally don't program... If I - or any other newbie - downloads the latest source of the latest build and start to try to compile it, I would be really disappointed if I get something else out that the official releases! Guess my first thing would be to compare the MD5s... and if they don't match, I guess I would ask at next any friend or in any forum what the reason can be, that Mozilla is shipping other pre-compiled builds then I get out if I compile by myself... Guess you can imagine that it wouldn't take anymore long before rumors come up that Mozilla is something hiding or tries to build in backdoors e.g. for the NSA... So I think: The default build config should _always_ be (in every project) the same as is used to build the pre-compiled builds!

(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #5) > (In reply to Mike Hommey [:glandium] from comment #1) > > (In reply to Henri Sivonen (:hsivonen) from comment #0) > > > Per > > > https://groups.google.com/d/msg/mozilla.dev.platform/v0QAe2olnH0/ > > > TivwVmhWOQAJ it's now OK to require SSE2 for Mozilla-made builds of Firefox > > > for Linux x86. > > > > > > Therefore, the build config for Mozilla-official builds as well as the > > > default build config (so that people develop with settings that match the > > > shipping config) should be changed to target SSE2 (i.e. turn on SSE2-based > > > IEEE-compliant floating point math and turn on SSE2 autovectorization). > > > > The more compelling argument is that what distros ship would be more > > different from what Mozilla ships. OTOH, there might be reasons for their > > compiler not defaulting to SSE2 enabled by default. For instance, both > > Ubuntu and Debian don't have GCC defaulting to SSE2 (or SSE for that > > matter). I don't know what the explicit choice is for Ubuntu, but for > > Debian, it's definitely an explicit choice that SSE is not enabled by > > default. I don't know about Fedora or other distros. > > I'm pretty sure that the real reason of the distros for doing this is, that > Linux/this distros are perfect to "recycle" old machines e.g. as gateways, > proxies, print-server, ... and "stupid machines" that do things like grid > computing, pinging, brute force, etc. ... > > As described in > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0 > there is really no logical reason to use FF in a real non-SSE2 environment! > I be also petty sure that no one will really recognize or miss it and this > was also the reason why I suggested a error msg in the next build to see if > really someone cares about it and if, if he fix it on his side (e.g. turn > SSE2-Support on in BIOS or set up a other machine), or if someone is really > disappointed about it and brings any real reason (a situation that don't > exist only theoretical) to change the decisions and plans of Mozilla. Bug 1096651 is a bug that was filed 1.5 years ago because someone was running Iceweasel on a Cyrix CPU-based machine, with MMX but without SSE (and where cpuid doesn't set rcx). I'm not going to make any judgement whether or not it's worth supporting those people, but they exist. > I'm involved in application development but normally don't program... > If I - or any other newbie - downloads the latest source of the latest build > and start to try to compile it, I would be really disappointed if I get > something else out that the official releases! > Guess my first thing would be to compare the MD5s... and if they don't > match, I guess I would ask at next any friend or in any forum what the > reason can be, that Mozilla is shipping other pre-compiled builds then I get > out if I compile by myself... Guess you can imagine that it wouldn't take > anymore long before rumors come up that Mozilla is something hiding or tries > to build in backdoors e.g. for the NSA... > So I think: The default build config should _always_ be (in every project) > the same as is used to build the pre-compiled builds! Obtaining the exact same binaries as those released by $entity involves much more than taking the sources and compiling them. You won't get the same binaries unless you use the same toolchain in the same environment (same paths for the sources, for the build directory, for the tools involved in the build, etc. etc.), and possibly other tricks (fiddling with timestamps, for example). Add to that the fact that Mozilla is doing PGO (Profile Guided Optimization) builds (where you build once, run the build, which gets a profile, and run the build again so that the compiler optimizes based on the profile), and you've got yourself something close to impossible to reproduce (except maybe if the profile data is provided along the source, the exact toolchain and the build environment). But really, that's offtopic here. Enabling SSE2 for everyone while preserving flexibility is not as trivial as it seems, which, combined with the fact we're in the middle of overhauling "configure", makes things more difficult.

(In reply to Mike Hommey [:glandium] from comment #6) > (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #5) > > As described in > > https://groups.google.com/forum/#!topic/mozilla.dev.platform/v0QAe2olnH0 > > there is really no logical reason to use FF in a real non-SSE2 environment! > > I be also petty sure that no one will really recognize or miss it and this > > was also the reason why I suggested a error msg in the next build to see if > > really someone cares about it and if, if he fix it on his side (e.g. turn > > SSE2-Support on in BIOS or set up a other machine), or if someone is really > > disappointed about it and brings any real reason (a situation that don't > > exist only theoretical) to change the decisions and plans of Mozilla. > > Bug 1096651 is a bug that was filed 1.5 years ago because someone was > running Iceweasel on a Cyrix CPU-based machine, with MMX but without SSE > (and where cpuid doesn't set rcx). I'm not going to make any judgement > whether or not it's worth supporting those people, but they exist. This is exactly the reason my I suggested a "test & fail"-solution that can be easily and fast un-done again! I want to find this "those people exist" and ask them what is special in there situation and what can be the best solution for all! Is it e.g. a BIOS setting, or a VM that have a bug, or what is it? And what needs to be done to fix this situation? E.g. making a bug report in a other project. This is why I want so give them a error message they can't just ignore! I want to get them active - no matter how. Fix it on there side or connect to the community and ask for help. > > I'm involved in application development but normally don't program... > > If I - or any other newbie - downloads the latest source of the latest build > > and start to try to compile it, I would be really disappointed if I get > > something else out that the official releases! > > Guess my first thing would be to compare the MD5s... and if they don't > > match, I guess I would ask at next any friend or in any forum what the > > reason can be, that Mozilla is shipping other pre-compiled builds then I get > > out if I compile by myself... Guess you can imagine that it wouldn't take > > anymore long before rumors come up that Mozilla is something hiding or tries > > to build in backdoors e.g. for the NSA... > > So I think: The default build config should _always_ be (in every project) > > the same as is used to build the pre-compiled builds! > > Obtaining the exact same binaries as those released by $entity involves much > more than taking the sources and compiling them. You won't get the same > binaries unless you use the same toolchain in the same environment (same > paths for the sources, for the build directory, for the tools involved in > the build, etc. etc.), and possibly other tricks (fiddling with timestamps, > for example). Add to that the fact that Mozilla is doing PGO (Profile Guided > Optimization) builds (where you build once, run the build, which gets a > profile, and run the build again so that the compiler optimizes based on the > profile), and you've got yourself something close to impossible to reproduce > (except maybe if the profile data is provided along the source, the exact > toolchain and the build environment). But really, that's offtopic here. I'm not much active in testing software from GitHub because they only give you source that you need to compile by yourself... The question for me is: Is this a project that release build and the code to it? Or is it a project/community that creates together a open source appp and compiles the code for those who won't do it by there self? I guess the second one... I can go e.g. to any page of a vendor of a router and can find the open-source sources they use and they have to supply for download... But it doesn't mean that I will be able to easily compile any functional out of it! They just do it, because they must! From a OSS-Project I expect to get the sources (like on GitHub) and if they are nice, they give me a binary to it... Think, that's the way it should go... If I want to try to compile Firefox I search in Google for "build firefox"... ...the first link I get is: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions I now expect to get a short (TL;DR) explanation what I have to do to compile the first time my own FF... Here I see a "Simple Firefox build" with a link to: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Firefox_build And I really don't wanna see there any explanations or (much worse) any questions (like: "What feature does your CPU support?") that make my first try really much more complicated! You know: TL;DR! If a experienced programmer (like you) want to build some special build with other setting, it's much easier for you to read additional documentations that explain special scenarios to advanced programmers then to not give a "Just get started"-Guide to a newbie where he get (almost) the same like if he download a _pre-compiled_ build. IMHO!

(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #7) > I want to find this "those people exist" and ask them what is special in > there situation and what can be the best solution for all! > Is it e.g. a BIOS setting, or a VM that have a bug, or what is it? I'm one of "those people". My PC has an AMD Athlon XP 2500+ CPU (which doesn't have SSE2 support) and runs Debian jessie with KDE4. I have no issues with browsing the Web, viewing and editing photos, watching HD videos, developing etc. Firefox runs flawlessly, without consuming too much RAM, freezing or crashing, and all web sites I visit work without problems. So saying that running Firefox on non-SSE2 CPUs has no sense is exaggeration at least. And I'm not the only one using such hardware. For example, when Chromium made SSE2 mandatory about 2 years ago, quite a lot of people were affected: * https://bugs.chromium.org/p/chromium/issues/detail?id=348761 * https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1353185 * https://forums.freebsd.org/threads/48002/ * https://otvet.mail.ru/question/170633384 (in Russian) * and many more: just search for 'chromium sse2'. > This is why I want so give them a error message they can't just ignore! Please bear in mind that some distributions (Debian, for example) ship the ESR version of Firefox, so their users won't see the message for quite a while.

My view is that we should continue to support non-SSE machines on linux32 until the point where we drop support for linux32 as a tier-1 platform. Most Linux users are using linux64 builds where SSE2 is always available. The performance argument that applies to Windows does not apply to Linux because most Linux users are using 64 bit. If we are going to drop support for non-SSE machines, most of which are Athlon XP CPUs, then we at the very least need to get our messaging right and stop this from looking like a crash. Right now it just looks like video playback is broken and I don't want to spend my days triaging video the bugs.

To quantify 'most' we have about 10% of our Firefox 48 linux users on 32-bit, based on telemetry reports. Nightly is more like 3%. But this is *significantly* down from the 40% claimed a year ago in https://bugzilla.mozilla.org/show_bug.cgi?id=1204920#c1 This is tricky to count because we're talking about official builds vs default builds vs downstream builds, which can all have different settings. Maybe most Ubuntu users have upgraded since then?

I'm not going to pull the trigger on this one. I've asked Ralph to disable the Rust stuff in 49 so we can unbreak everything in the meanwhile.

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #9) > My view is that we should continue to support non-SSE machines on linux32 > until the point where we drop support for linux32 as a tier-1 platform. In the message referenced by comment 0, bsmedberg said: "Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am comfortable making that decision today." I read that as the decision to drop non-SSE2 in Linux x86 builds produced by Mozilla was already made.

> I read that as the decision to drop non-SSE2 in Linux x86 builds produced by Mozilla was already made. As did I. I do agree with Anthony that we need a better update story when we do this, though. This should block on bug 1277359 (the Linux version of bug 1271762) so we don't send people builds which won't work on their hardware. He also thought we should run cpuid detection at the beginning of main() and die with a console error/gui notification if SSE2 isn't available as a hint to packagers, since unlike Windows we don't provide a linux installer package which can assert this. That sounds like a lot of special casing to me if we're correct about the declining relevance of linux32, but it's worth considering.

Comment on attachment 8798378 [details] [diff] [review] Use SSE2 in Mozilla's builds (In reply to Mike Hommey [:glandium] from comment #1) > With all that being said, people already don't develop with settings that > match the shipping config, which does PGO, so it's not really a compelling > argument anyways. And most people are doing x86-64 builds anyways. Let's focus on Mozilla's builds and not on what one gets when checking out the code and building on 32-bit x86 without moconfig customizations. > Anyways, all that to say that it's way too early IMHO to make a decision for > them, so for now at least, I'd stick with modifying our mozconfigs and > nothing else. OK. This patch modifies only our automation mozconfig. > We'll want -msse2 -mfpmath=sse to replace -march=pentiumpro. I added -msse -msse2 -mfpmath=sse but I didn't remove -march=pentiumpro, because the existing comments suggested that when compiling for 32-bit on a 64-bit host, the GCC defaults might differ from compiling for 32-bit on a 32-bit host, and I'm not sure what the entire implications might be. Note that the patch in bug 1300843 assumes that if -msse, -msse2 and -mfpmath=sse are filtered out of the flags, the result is something that runs without SSE/SSE2. However, it seems rather silly to tune instruction scheduling etc. for a legacy CPU we'll no longer be able run on, so maybe we should add -mtune for something newer. I'm not sure what, though. > Autovectorization is an optimization pass that is enabled at -O3. Our > default is to build the js engine at -O3 and gecko at -Os, except on PGO > builds, which use -O3 (with GCC then tweaking optimizations levels on cold > code ; presumably that means it can disable autovectorization on cold code). > I'd say we don't need to explicitly enable autovectorization. OK. > I wouldn't be surprised if the switch of floating point type breaks things > like some reftests. So, I'd suggest a try push, too. The most recent try run is all-green. (The previous one had an unrelated changeset that got backed out.)

Comment on attachment 8798378 [details] [diff] [review] Use SSE2 in Mozilla's builds Review of attachment 8798378 [details] [diff] [review]: ----------------------------------------------------------------- cf. comments in bug 1300843.

Comment on attachment 8803238 [details] [diff] [review] Use pentium-m, turn on the SSE2 error on Mozilla build infra Review of attachment 8803238 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/unix/mozconfig.linux32 @@ +10,2 @@ > if test `uname -m` = "x86_64"; then > + CC="$CC -m32" IIRC, we don't necessarily propagate CFLAGS and CXXFLAGS to every third party library, so it would actually be better to keep the architecture flags in CC/CXX.

bhearsum, is Balrog ready for this to land (making 32-bit x86 Linux builds no longer run without SSE2)? Considering that SSE detection was uplifted to 51, trunk is now 53 and 52 is ESR, I suggest having these rules in place: * 50 or earlier update to 52. * 51 and 52 update to latest release if SSE2 is present and to latest ESR 52 if SSE2 is not available. The part about moving non-SSE2 users to ESR probably needs a higher-up decision. bsmedberg, does moving non-SSE2 x86 Linux 32-bit to ESR seem like a worthwhile idea? Alternatively, we could uplift this and bug 1300843 to 52 and not support non-ESR for the 52 ESR cycle.

We're not going to mess with moving users to ESR. We're just going to stop support. I am not sure whether we already did that for Linux or only for Windows in bug 1271762

(In reply to Benjamin Smedberg [:bsmedberg] from comment #26) > We're not going to mess with moving users to ESR. We're just going to stop > support. OK. > I am not sure whether we already did that for Linux or only for > Windows in bug 1271762 We didn't for Linux. This is the bug to stop non-SSE2 support for Linux. bhearsum, so to revise what I said in comment 25, I suggest having the following rules: * 50 or earlier update to 52. * 51 and 52 update to latest release if SSE2 is present. * 51 updates to 52 if SSE2 is absent. * 52 shows a link to a tombstone SUMO article if SSE2 is absent.

(In reply to Henri Sivonen (:hsivonen) from comment #27) > (In reply to Benjamin Smedberg [:bsmedberg] from comment #26) > > We're not going to mess with moving users to ESR. We're just going to stop > > support. > > OK. > > > I am not sure whether we already did that for Linux or only for > > Windows in bug 1271762 > > We didn't for Linux. This is the bug to stop non-SSE2 support for Linux. > > bhearsum, so to revise what I said in comment 25, I suggest having the > following rules: > * 50 or earlier update to 52. > * 51 and 52 update to latest release if SSE2 is present. > * 51 updates to 52 if SSE2 is absent. > * 52 shows a link to a tombstone SUMO article if SSE2 is absent. No code changes needed to Balrog for this. Can you file a bug in RelEng: Releases for this? I'll make sure it gets some attention.

(In reply to Ben Hearsum (:bhearsum) from comment #28) > Can you file a bug in RelEng: > Releases for this? I'll make sure it gets some attention. Already filed: bug 1308167. I'll land the patch here once the Balrog rules are in place.

https://hg.mozilla.org/integration/mozilla-inbound/rev/f1b7ef2430dac82e557590e51c38f56241366751 Bug 1274196 - Turn on SSE2 autovectorization and SSE2-based floating-point math for 32-bit Linux. r=glandium.

Release Note Request (optional, but appreciated) > [Why is this notable]: Some computers that were previously able to run Mozilla-shipped Firefox can no longer run Mozilla-shipped non-ESR Firefox. > [Affects Firefox for Android]: No. > [Suggested wording]: Firefox on 32-bit x86 Linux now requires a processor that supports the SSE2 instruction set extension, which is not available on processors older than Pentium 4. Firefox Extended Support Release (ESR) will continue to work without SSE2 through the ESR 52 cycle. Some Linux distributions may choose to distribute an up-to-date version of Firefox that does not require SSE2. > [Links (documentation, blog post, etc)]: https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported (Note: The content of the SUMO page depends on the OS advertised in the UA string, and the Linux content differs from the Windows content. The corresponding change was made in Firefox 49 for Windows.)

It may be worth saying "Intel Pentium 4 and AMD Opteron" rather than just "Pentium 4".

Added to Fx53 Aurora release notes.

(In reply to Ritu Kothari (:ritu) from comment #34) > Added to Fx53 Aurora release notes. Based on https://www.mozilla.org/en-US/firefox/53.0a2/auroranotes/ , it looks like my suggested wording was rejected and the old wording from the 49 release notes was used instead. (The note now says: "Ended Firefox Linux support for SSE processors") "SSE processors" may cause confusion. We are ending support for processors that don't have SSE2. That includes processors without any kind of SSE and processors with SSE only. Moreover, the processors we do support include SSE support (along with SSE2 and later). Could it be reworded to either "Ended Firefox Linux support for processors older than Pentium 4 and AMD Opteron" or if even that's too long "Ended Firefox Linux support for processors that don't support SSE2"?

"Ended Firefox Linux support for SSE processors" would cause me as an technically minded end-user to raise an eyebrow because literally ever major processor made today supports the SSE instructions. So the statement isn't accurate. I like the suggested wording of "older than Pentium 4 and AMD Opteron" because that is something that less technically minded users can more easily check (most users don't know or care what SSE or SSE2 are).

Hi Henri, GPS, I've updated the relnote wording to "Ended Firefox Linux support for processors older than Pentium 4 and AMD Opteron". Thanks for the due diligence.