On Wed, May 18, 2016 at 6:54 AM, Mike Hommey <m...@glandium.org> wrote:
> Henri Sivonen wrote:
>
> > It seems that we are almost ready to require SSE2 for Mozilla-built
> > Firefox for 32-bit x86 Linux.
>
There are a couple of interrelated issues here.
Can we require SSE2 for Mozilla builds of Firefox for Linux? Yes, I am
comfortable making that decision today.
Should we also take actions that prevent anyone from supporting non-SSE2
codepaths? I don't know. There seem to be at least a few cases that this
affects:
- Rust and its support for non-SSE2 arches
- This seems to be both about build-time targeting and runtime
dynamic selection. I don't personally understand the
cost/benefit tradeoff
here.
- Our own JITs and their support for non-SSE2 paths
- Our primary JIT doesn't support non-SSE2, right? So these users
already fall back to the slow interpretation path?
- Other platform code that does dynamic SSE2 detection. For example,
image decoders which we compiler in both SSE2 and non-SSE2 configs
currently, and select the codepath at runtime.
- I imagine we'd like to remove this complexity from the tree,
especially given that we won't have any testing for it.
- Our relationships with 3rd-party code, in particular Flash,
OpenH264, Widevine, and Primetime
- Some of these already don't support non-SSE2 and may not ever.
> Now, with my Debian hat on, I can tell you with 100% certainty that
> angry Debian users *will* come with patches and will return even
> angrier if patches are not even welcome.
>
In the abstract, I'm willing to accept the cost of a minority of angry
users for an offsetting benefit; that benefit can either be perf
improvements or maintenance/development improvements in the Firefox
codebase. I just don't understand the costs yet.
> That said, Talos could tell something different, but I'm not convinced
> building with SSE2 would make a huge difference. Things where it does
> make huge differences are already using run-time selected SSE2 code.
> And even if it does make huge differences, I'm tempted to say "so what"?
> So, if people want to build the same way as currently, even if Mozilla
> and most distros end up defaulting to SSE2, why prevent them from doing
> so? Why specifically not welcome patches, instead of, say, making it
> tier-3, like e.g. sparc or mips?
>
One obvious cost is either continued testing of the runtime selection
codepaths, *or* releasing code which we haven't tested. And the mental
overhead of changing that code. Although I bet we aren't testing the
non-SSE2 codepaths even right now, given how hard it has been to find any
machine at Mozilla that didn't have SSE2.
If we're going to accidentally keep introducing bugs where non-SSE2 CPUs
crash, it would be far better to add a runtime check at the beginning of
main() and error out, than to have a steady trickle of bug reports about
crashes on illegal instructions which end up being marked INVALID.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
