Reverting to VS2013 on central and aurora

[Gregory Szorc]

There is a compiler bug in VS2015 that results in SSE instructions being
emitted when they shouldn't be. Since Firefox still needs to remain
compatible with ancient hardware that doesn't support SSE, this is causing
crashes on Firefox built with VS2015 (see bug 1265615).

The good news is glandium found a pretty minimal reproduce case and
reported the bug to Microsoft.

The bad news is the issue still reproduces in the latest pre-release
version of the Visual C++ toolchain.

The worse news is we'll have to revert to building Firefox 48 (current
Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
track. Aurora will likely land soon. Central might take a few days, as I
believe VS2013 is a bit broken on central at the moment.

This is really a bummer because a lot of you have taken the time to upgrade
to VS2015 and we got some really nice PGO build time wins out of the
transition (Windows PGO builds were just as fast as Linux PGO builds in
automation). But, stability is stability.

I'll try to stand up automation to ensure central remains buildable with
VS2015. This will add extra work and strain on automation and likely make
writing C++ that remains compatible with multiple Visual Studio versions
slightly harder. This is unfortunate, but I think necessary since people
will want to use VS2015 for development.

FWIW, the crashes we've seen so far are from incorrectly emitted movss
instructions. This instruction is part of the original SSE instruction set,
which was initially unveiled by Intel on the Pentium 3 in 1999 and later by
AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still need
Firefox to run on processors manufactured in the 90s. By comparison, Chrome
has required SSE2 (Intel support since Pentium 4 in 2001 and AMD support
since Opteron and Athlon 64 in 2003) since Chrome 35, which was released in
mid 2014 (https://bugs.chromium.org/p/chromium/issues/detail?id=348761).
Since we've dropped support for OS X <10.9 and are talking about dropping
Windows XP support, I'd urge us to consider dropping support for processors
without SSE instructions as well. I believe our continued insistence to
support these ancient platforms hinders our developer productivity and
sacrifices product quality by not allowing us to take advantage of modern
technologies. I believe this puts us at a competitive disadvantage compared
to other browser vendors. </soapbox_mini_rant>

[Chris Peterson]

On 5/5/16 9:26 PM, Gregory Szorc wrote:
> I'll try to stand up automation to ensure central remains buildable with
> VS2015. This will add extra work and strain on automation and likely make
> writing C++ that remains compatible with multiple Visual Studio versions
> slightly harder. This is unfortunate, but I think necessary since people
> will want to use VS2015 for development.

Can we continue to build Windows x64 with VS2015? That would ensure code
is still buildable with VS2015, take advantage of newer optimizations
and warnings, and have little (?) infrastructure overhead compared to
using VS2013.

[Mike Hommey]

That's a good point, and there's no concern about SSE on 64-bits, since
SSE and SSE2 are part of the base x86-64 instruction set.

Mike

[Mike Hoye]

On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> FWIW, the crashes we've seen so far are from incorrectly emitted movss
> instructions. This instruction is part of the original SSE instruction set,
> which was initially unveiled by Intel on the Pentium 3 in 1999 and later by
> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still need
> Firefox to run on processors manufactured in the 90s.

Per an IRC conversation with chutten, Firefox users on CPUs that do not
support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2).
A third of those are on otherwise-unsupported configurations (pre-SP3
XP, etc), this work provides continuity of support to 0.01% of our users.

- mhoye


09:59 <chutten> So, to put it clearly and precisely, of the Firefox
Population in release and beta who are reporting at least base telemetry
collection on machines running supported configurations, only 0.01%
cannot definitively say they have SSE.
10:00 <chutten> (according to a 1% random sample as stored in the
longitudinal dataset)

[Kyle Huey]

I think we should strongly consider just requiring SSE at this point.

- Kyle

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Gregory Szorc]

On Fri, May 6, 2016 at 7:10 AM, Mike Hoye <mh...@mozilla.com> wrote:

> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>
>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>> instructions. This instruction is part of the original SSE instruction
>> set,
>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>> by
>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>> need
>> Firefox to run on processors manufactured in the 90s.
>>
> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> etc), this work provides continuity of support to 0.01% of our users.
>

This population (0.015%) is ~100x smaller than the OS X 10.6-10.8 users we
just decided to drop (going by bsmedberg's quote of 1.2% in the OS X
deprecation thread). Looking at the numbers alone, I can't see how we
wouldn't arrive at the conclusion to require SSE. Beyond the numbers, the
modern web must be a horrible experience on ancient processors and machines
not supporting SSE. I'm not sure what value continuing to provide Firefox
updates to this population will add.

Reverting to VS2013 will have an unplanned negative impact on developers
and automation. Reverting to VS2013 then deciding a short time after that
we can use VS2015/SSE after all will have even more negative impact. It is
desirable to avoid both these things. Therefore *I'm going to not move
forward with reverting aurora and central to VS2013 unless someone says
otherwise*. I have cancelled the aurora uplift requests in bug 1270664
until a decision is made.

[Benjamin Smedberg]

I agree that we should drop support for non-SSE2. It mattered 7 years ago
(see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
doesn't matter now.

We do need to avoid updating these users to a build that will crash, and do
the same "unsupported" messaging we're doing for old versions of MacOS.
Gregory, will you own that? You will probably need to add CPU feature
detection to the update URL/params for 47, or use some kind of system addon
to shunt these users off the main update path.

--BDS

On Fri, May 6, 2016 at 10:10 AM, Mike Hoye <mh...@mozilla.com> wrote:

> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>
>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>> instructions. This instruction is part of the original SSE instruction
>> set,
>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>> by
>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>> need
>> Firefox to run on processors manufactured in the 90s.
>>
> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> etc), this work provides continuity of support to 0.01% of our users.
>

[Gregory Szorc]

On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg <benj...@smedbergs.us>
wrote:

> I agree that we should drop support for non-SSE2. It mattered 7 years ago
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> doesn't matter now.
>

Wait - are we talking about requiring SSE or SSE2? The thread up to this
point was talking about requiring just SSE, not SSE2. I just want to make
sure we're on the same page since according to mhoye's post the non-SSE2
population is ~25x larger than the non-SSE population...

>
> We do need to avoid updating these users to a build that will crash, and
> do the same "unsupported" messaging we're doing for old versions of MacOS.
> Gregory, will you own that? You will probably need to add CPU feature
> detection to the update URL/params for 47, or use some kind of system addon
> to shunt these users off the main update path.
>

Given that 47 is in Beta, is it too late/risky to make this change on that
channel? Should we revert to VS2013 on Aurora/48 and make the updater
modifications on that channel? I think this will have minimal negative
impact, as most of the impact to changing toolchains would be on central,
as that is where most developers and automation live.

[Milan Sreckovic]

If it matters for this discussion, I’m pretty sure central doesn’t build with VS2013 today. At least it doesn’t for me.
—
- Milan

[Milan Sreckovic]

While I agree we should drop non-SSE (and have started a conversation to drop non-SSE2 as well :), the comparison to dropping 10.6-10.8 users is somewhat unfair. Those users can upgrade 10.9 easier than the non-SSE users can buy a new computer.
—
- Milan



> On May 6, 2016, at 12:22 , Gregory Szorc <g...@mozilla.com> wrote:

>
> On Fri, May 6, 2016 at 7:10 AM, Mike Hoye <mh...@mozilla.com <mailto:mh...@mozilla.com>> wrote:
>
>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>>
>>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>>> instructions. This instruction is part of the original SSE instruction
>>> set,
>>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>>> by
>>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>>> need
>>> Firefox to run on processors manufactured in the 90s.
>>>
>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>> etc), this work provides continuity of support to 0.01% of our users.
>>
>

> This population (0.015%) is ~100x smaller than the OS X 10.6-10.8 users we
> just decided to drop (going by bsmedberg's quote of 1.2% in the OS X
> deprecation thread). Looking at the numbers alone, I can't see how we
> wouldn't arrive at the conclusion to require SSE. Beyond the numbers, the
> modern web must be a horrible experience on ancient processors and machines
> not supporting SSE. I'm not sure what value continuing to provide Firefox
> updates to this population will add.
>
> Reverting to VS2013 will have an unplanned negative impact on developers
> and automation. Reverting to VS2013 then deciding a short time after that
> we can use VS2015/SSE after all will have even more negative impact. It is
> desirable to avoid both these things. Therefore *I'm going to not move
> forward with reverting aurora and central to VS2013 unless someone says
> otherwise*. I have cancelled the aurora uplift requests in bug 1270664
> until a decision is made.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org <mailto:dev-pl...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform <https://lists.mozilla.org/listinfo/dev-platform>

[Henri Sivonen]

On Fri, May 6, 2016 at 8:17 PM, Gregory Szorc <g...@mozilla.com> wrote:
> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg <benj...@smedbergs.us>
> wrote:
>
>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>> doesn't matter now.
>>
>
> Wait - are we talking about requiring SSE or SSE2? The thread up to this
> point was talking about requiring just SSE, not SSE2. I just want to make
> sure we're on the same page since according to mhoye's post the non-SSE2
> population is ~25x larger than the non-SSE population...

What does requiring SSE without requiring SSE2 buy us apart from
VS2015 compat? Is it enough to fully avoid x87-style non-IEEE floating
point math? (SSE2 is usually cited when talking about migrating from
x87 to IEEE.)

It seems that requiring SSE2 is the typical discontinuity point as
seen in Windows itself, Chromium, Rust, various codec optimizations,
C++ compiler defaults (MSVC and, I believe, clang), etc.

That is to say, I hope the outcome here is that we start requiring SSE2.

On Fri, May 6, 2016 at 9:11 PM, Milan Sreckovic <msrec...@mozilla.com> wrote:
> While I agree we should drop non-SSE (and have started a conversation to drop non-SSE2 as well :), the comparison to dropping 10.6-10.8 users is somewhat unfair. Those users can upgrade 10.9 easier than the non-SSE users can buy a new computer.

Upgrading from Mac OS X 10.6 can be more expensive than buying a new
entry-level Windows PC if what kept you on 10.6 was expensive PPC-era
proprietary software (e.g. PPC-era Creative Suite for casual enough
use that you don't need the latest for the features). Also, some Macs
can't upgrade beyond 10.7. So the comparison is fairer than it first
may seem.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Milan Sreckovic]

For graphics, it’s performance if we start requiring SSE2. Lately, canvasmark benchmark, and increasingly more trouble when updating Skia library.
—
- Milan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-platform

[Emanuel Hoogeveen]

SSE2 is also required for IonMonkey, our optimizing JIT. The baseline compiler does work without SSE2, but isn't nearly as fast. So users running Firefox on hardware without SSE2 support are already getting severely degraded performance.

On Friday, May 6, 2016 at 10:59:01 PM UTC+2, Milan Sreckovic wrote:
> For graphics, it's performance if we start requiring SSE2. Lately, canvasmark benchmark, and increasingly more trouble when updating Skia library.

> --

[Mike Hommey]

On Fri, May 06, 2016 at 07:38:31PM -0700, Emanuel Hoogeveen wrote:
> SSE2 is also required for IonMonkey, our optimizing JIT. The baseline
> compiler does work without SSE2, but isn't nearly as fast. So users
> running Firefox on hardware without SSE2 support are already getting
> severely degraded performance.

Heh, more importantly than the lack of SSE2, the very fact that those
are old processors makes them have degraded performance in the first
place. So, in fact, the lack of SSE2 is the least of their problem.

Mike

[Emanuel Hoogeveen]

Well, I think that's debatable ;) The Athlon XP had clock speeds of up to 2333MHz, though I'm sure the per-clock performance doesn't measure up to current offerings. But Ion can easily be 5x as fast as Baseline. Of course, whether that makes a difference depends on what JS you're running. But either way, people with these processors are getting a double whammy of degraded performance.

[Gregory Szorc]

On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote:

> There is a compiler bug in VS2015 that results in SSE instructions being
> emitted when they shouldn't be. Since Firefox still needs to remain
> compatible with ancient hardware that doesn't support SSE, this is causing
> crashes on Firefox built with VS2015 (see bug 1265615).
>
> The good news is glandium found a pretty minimal reproduce case and
> reported the bug to Microsoft.
>
> The bad news is the issue still reproduces in the latest pre-release
> version of the Visual C++ toolchain.
>
> The worse news is we'll have to revert to building Firefox 48 (current
> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> track. Aurora will likely land soon. Central might take a few days, as I
> believe VS2013 is a bit broken on central at the moment.
>

We have a change in plans.

bsmedberg says we can require SSE. So that means the VS2015 bug emitting
SSE instructions isn't an issue.

But we need to teach the updater to advertise CPU features in the Firefox
version before we drop SSE so we don't update users to a binary that won't
work. Since Firefox 48/Aurora is currently using VS2015, that would mean
teaching Firefox 47/Beta new tricks. Since we're already in the middle of
the Beta cycle and there is no major user benefit to shipping VS2015 builds
at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
continue to build with VS2015 and will be the first Firefox version to
require SSE.

Bug 1271755 is our tracker for requiring SSE to run Firefox.

[Ehsan Akhgari]

On 2016-05-10 4:45 PM, Gregory Szorc wrote:
> On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote:
>
>> There is a compiler bug in VS2015 that results in SSE instructions being
>> emitted when they shouldn't be. Since Firefox still needs to remain
>> compatible with ancient hardware that doesn't support SSE, this is causing
>> crashes on Firefox built with VS2015 (see bug 1265615).
>>
>> The good news is glandium found a pretty minimal reproduce case and
>> reported the bug to Microsoft.
>>
>> The bad news is the issue still reproduces in the latest pre-release
>> version of the Visual C++ toolchain.
>>
>> The worse news is we'll have to revert to building Firefox 48 (current
>> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
>> track. Aurora will likely land soon. Central might take a few days, as I
>> believe VS2013 is a bit broken on central at the moment.
>>
>
> We have a change in plans.
>
> bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> SSE instructions isn't an issue.

Firstly, great to hear this!

But since the topic of when to drop support for legacy platforms seems
to be coming up a few times per week these days, it would be helpful to
document somewhere how the decision to drop support for processors not
supporting SSE was reached. Do we have data covering what number of
users will be affected by this change? Do we have guidelines on what's
the threshold for supporting other similar legacy configs?

It would be helpful to see some information about this shared here.

Thanks,
Ehsan

[Xidorn Quan]

On Wed, May 11, 2016 at 6:45 AM, Gregory Szorc <g...@mozilla.com> wrote:

> On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote:
>
> > There is a compiler bug in VS2015 that results in SSE instructions being
> > emitted when they shouldn't be. Since Firefox still needs to remain
> > compatible with ancient hardware that doesn't support SSE, this is
> causing
> > crashes on Firefox built with VS2015 (see bug 1265615).
> >
> > The good news is glandium found a pretty minimal reproduce case and
> > reported the bug to Microsoft.
> >
> > The bad news is the issue still reproduces in the latest pre-release
> > version of the Visual C++ toolchain.
> >
> > The worse news is we'll have to revert to building Firefox 48 (current
> > Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> > track. Aurora will likely land soon. Central might take a few days, as I
> > believe VS2013 is a bit broken on central at the moment.
> >
>
> We have a change in plans.
>
> bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> SSE instructions isn't an issue.
>

> But we need to teach the updater to advertise CPU features in the Firefox
> version before we drop SSE so we don't update users to a binary that won't
> work. Since Firefox 48/Aurora is currently using VS2015, that would mean
> teaching Firefox 47/Beta new tricks. Since we're already in the middle of
> the Beta cycle and there is no major user benefit to shipping VS2015 builds
> at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
> build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
> continue to build with VS2015 and will be the first Firefox version to
> require SSE.
>
> Bug 1271755 is our tracker for requiring SSE to run Firefox.
>

As we are dropping another set of users in Firefox 48 in addition to OS X
10.6~10.8, could we reconsider making Firefox 48 a half-ESR as I proposed
in [1]?

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/gXZj0rQWEfI/RIeuLYTvAAAJ

- Xidorn

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> On 2016-05-10 4:45 PM, Gregory Szorc wrote:
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote:
> >
> >> There is a compiler bug in VS2015 that results in SSE instructions being
> >> emitted when they shouldn't be. Since Firefox still needs to remain
> >> compatible with ancient hardware that doesn't support SSE, this is
> causing
> >> crashes on Firefox built with VS2015 (see bug 1265615).
> >>
> >> The good news is glandium found a pretty minimal reproduce case and
> >> reported the bug to Microsoft.
> >>
> >> The bad news is the issue still reproduces in the latest pre-release
> >> version of the Visual C++ toolchain.
> >>
> >> The worse news is we'll have to revert to building Firefox 48 (current
> >> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> >> track. Aurora will likely land soon. Central might take a few days, as I
> >> believe VS2013 is a bit broken on central at the moment.
> >>
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
>

> Firstly, great to hear this!
>
> But since the topic of when to drop support for legacy platforms seems
> to be coming up a few times per week these days, it would be helpful to
> document somewhere how the decision to drop support for processors not
> supporting SSE was reached. Do we have data covering what number of
> users will be affected by this change? Do we have guidelines on what's
> the threshold for supporting other similar legacy configs?
>
> It would be helpful to see some information about this shared here.
>

> I don't know how this specific decision was reached but I did speak with
Chris Cooper and Peter Dolanjski about developing criteria/guidelines for
support today. I don't expect us to have something this month but we will
flesh this out as part of the ongoing conversation about platform support.

Lawrence

[Lawrence Mandel]

On Tue, May 10, 2016 at 7:29 PM, Xidorn Quan <quanx...@gmail.com> wrote:

> On Wed, May 11, 2016 at 6:45 AM, Gregory Szorc <g...@mozilla.com> wrote:
>
> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com> wrote:
> >
> > > There is a compiler bug in VS2015 that results in SSE instructions
> being
> > > emitted when they shouldn't be. Since Firefox still needs to remain
> > > compatible with ancient hardware that doesn't support SSE, this is
> > causing
> > > crashes on Firefox built with VS2015 (see bug 1265615).
> > >
> > > The good news is glandium found a pretty minimal reproduce case and
> > > reported the bug to Microsoft.
> > >
> > > The bad news is the issue still reproduces in the latest pre-release
> > > version of the Visual C++ toolchain.
> > >
> > > The worse news is we'll have to revert to building Firefox 48 (current
> > > Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> > > track. Aurora will likely land soon. Central might take a few days, as
> I
> > > believe VS2013 is a bit broken on central at the moment.
> > >
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
> >

> > But we need to teach the updater to advertise CPU features in the Firefox
> > version before we drop SSE so we don't update users to a binary that
> won't
> > work. Since Firefox 48/Aurora is currently using VS2015, that would mean
> > teaching Firefox 47/Beta new tricks. Since we're already in the middle of
> > the Beta cycle and there is no major user benefit to shipping VS2015
> builds
> > at this time, we're going to revert to VS2013 on Firefox 48/Aurora and
> > build the updater support into Firefox 48/Aurora. Firefox 49/Nightly will
> > continue to build with VS2015 and will be the first Firefox version to
> > require SSE.
> >
> > Bug 1271755 is our tracker for requiring SSE to run Firefox.
> >
>
> As we are dropping another set of users in Firefox 48 in addition to OS X
> 10.6~10.8, could we reconsider making Firefox 48 a half-ESR as I proposed
> in [1]?
>
> [1]
>
> https://groups.google.com/d/msg/mozilla.dev.platform/gXZj0rQWEfI/RIeuLYTvAAAJ

What you're suggesting is to continue providing support for these platforms
for a longer period of time. The intention is to stop supporting these
platforms. We have already made the decision (and in the case of OSX
announced it). I don't think we have good cause to change this decision at
this point.

Lawrence

[Lawrence Mandel]

On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg <benj...@smedbergs.us>

wrote:

> I agree that we should drop support for non-SSE2. It mattered 7 years ago
> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> doesn't matter now.
>

> We do need to avoid updating these users to a build that will crash, and do
> the same "unsupported" messaging we're doing for old versions of MacOS.
> Gregory, will you own that? You will probably need to add CPU feature
> detection to the update URL/params for 47, or use some kind of system addon
> to shunt these users off the main update path.
>

Benjamin - We're likely going to want to do this again in the future. Not
that Greg isn't capable but is there someone more familiar with the update
system who can step in to get this done?

Lawrence


>
> --BDS

>
>
> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye <mh...@mozilla.com> wrote:
>
> > On 2016-05-06 12:26 AM, Gregory Szorc wrote:
> >
> >> FWIW, the crashes we've seen so far are from incorrectly emitted movss
> >> instructions. This instruction is part of the original SSE instruction
> >> set,
> >> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
> >> by
> >> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
> >> need
> >> Firefox to run on processors manufactured in the 90s.
> >>
> > Per an IRC conversation with chutten, Firefox users on CPUs that do not
> > support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2).
> A
> > third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> > etc), this work provides continuity of support to 0.01% of our users.
> >

> > - mhoye
> >
> >
> > 09:59 <chutten> So, to put it clearly and precisely, of the Firefox
> > Population in release and beta who are reporting at least base telemetry
> > collection on machines running supported configurations, only 0.01%
> cannot
> > definitively say they have SSE.
> > 10:00 <chutten> (according to a 1% random sample as stored in the
> > longitudinal dataset)
> >

[Xidorn Quan]

On Wed, May 11, 2016 at 11:51 AM, Lawrence Mandel <lma...@mozilla.com>
wrote:

We have to do that for ESR 45 anyway, right? That means people would have
to either abandon their platform, or downgrade to ESR 45 for a longer
period security support. I'm proposing that we make 48 a special version
which ends support at the same time ESR 45 does, so that people can keep in
Firefox 48 and continue receiving security fixes for a while as long as we
are still supporting an even older version which supports those platforms.

- Xidorn

[Robert Strong]

On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel <lma...@mozilla.com>
wrote:

> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg <benj...@smedbergs.us>
> wrote:
>
> > I agree that we should drop support for non-SSE2. It mattered 7 years ago
> > (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
> > doesn't matter now.
> >
> > We do need to avoid updating these users to a build that will crash, and
> do
> > the same "unsupported" messaging we're doing for old versions of MacOS.
> > Gregory, will you own that? You will probably need to add CPU feature
> > detection to the update URL/params for 47, or use some kind of system
> addon
> > to shunt these users off the main update path.
> >
>
> Benjamin - We're likely going to want to do this again in the future. Not
> that Greg isn't capable but is there someone more familiar with the update
> system who can step in to get this done?
>

The majority of this involves getting whether the CPU supports SSE. The app
update part involves inserting the value into the url.

Having said that, I've already started looking at this today. It would be
good to know whether this info will be needed on other platforms at some
point as well.

Robert

[Ehsan Akhgari]

On 2016-05-10 10:01 PM, Robert Strong wrote:
> On Tue, May 10, 2016 at 6:55 PM, Lawrence Mandel <lma...@mozilla.com>
> wrote:
>
>> On Fri, May 6, 2016 at 12:39 PM, Benjamin Smedberg <benj...@smedbergs.us>
>> wrote:
>>
>>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>>> doesn't matter now.
>>>
>>> We do need to avoid updating these users to a build that will crash, and
>> do
>>> the same "unsupported" messaging we're doing for old versions of MacOS.
>>> Gregory, will you own that? You will probably need to add CPU feature
>>> detection to the update URL/params for 47, or use some kind of system
>> addon
>>> to shunt these users off the main update path.
>>>
>>
>> Benjamin - We're likely going to want to do this again in the future. Not
>> that Greg isn't capable but is there someone more familiar with the update
>> system who can step in to get this done?
>>
> The majority of this involves getting whether the CPU supports SSE. The app
> update part involves inserting the value into the url.

In theory you should be able to lift that code from
<https://dxr.mozilla.org/mozilla-central/source/js/src/jit/x86-shared/Assembler-x86-shared.cpp#219>.
Unfortunately I don't think this is exported from the JS engine, but
should be possible to copy the CPU feature detection parts out of it.

[Ehsan Akhgari]

On 2016-05-10 9:43 PM, Lawrence Mandel wrote:
> On Tue, May 10, 2016 at 7:05 PM, Ehsan Akhgari <ehsan....@gmail.com

> <mailto:ehsan....@gmail.com>> wrote:
>
> On 2016-05-10 4:45 PM, Gregory Szorc wrote:

> > On Thu, May 5, 2016 at 9:26 PM, Gregory Szorc <g...@mozilla.com <mailto:g...@mozilla.com>> wrote:
> >
> >> There is a compiler bug in VS2015 that results in SSE instructions being
> >> emitted when they shouldn't be. Since Firefox still needs to remain
> >> compatible with ancient hardware that doesn't support SSE, this is causing
> >> crashes on Firefox built with VS2015 (see bug 1265615).
> >>
> >> The good news is glandium found a pretty minimal reproduce case and
> >> reported the bug to Microsoft.
> >>
> >> The bad news is the issue still reproduces in the latest pre-release
> >> version of the Visual C++ toolchain.
> >>
> >> The worse news is we'll have to revert to building Firefox 48 (current
> >> Aurora) and 49 (current central) with VS2013. Bugs 1270664 and 1270714
> >> track. Aurora will likely land soon. Central might take a few days, as I
> >> believe VS2013 is a bit broken on central at the moment.
> >>
> >
> > We have a change in plans.
> >
> > bsmedberg says we can require SSE. So that means the VS2015 bug emitting
> > SSE instructions isn't an issue.
>

> Firstly, great to hear this!
>
> But since the topic of when to drop support for legacy platforms seems
> to be coming up a few times per week these days, it would be helpful to
> document somewhere how the decision to drop support for processors not
> supporting SSE was reached. Do we have data covering what number of
> users will be affected by this change? Do we have guidelines on what's
> the threshold for supporting other similar legacy configs?
>
> It would be helpful to see some information about this shared here.
>
> I don't know how this specific decision was reached but I did speak with
> Chris Cooper and Peter Dolanjski about developing criteria/guidelines
> for support today. I don't expect us to have something this month but we
> will flesh this out as part of the ongoing conversation about platform
> support.

Thank you, that would be super helpful!

[Jeff Muizelaar]

Or mozglue/build/SSE.cpp

-Jeff

On Wed, May 11, 2016 at 9:35 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

[Benjamin Smedberg]

I am talking about requiring SSE2. That is a larger (but still quite small)
population, but the upside of being able to turn on SSE2 optimizations by
default is an important benefit. I've discussed and confirmed this with
Firefox product management.

So yes, the plan of record is to require SSE2 starting in Firefox 49, and I
will update the tracking bugs to reflect that.

--BDS

On Fri, May 6, 2016 at 1:17 PM, Gregory Szorc <g...@mozilla.com> wrote:

> On Fri, May 6, 2016 at 9:39 AM, Benjamin Smedberg <benj...@smedbergs.us>

> wrote:
>
>> I agree that we should drop support for non-SSE2. It mattered 7 years ago
>> (see https://bugzilla.mozilla.org/show_bug.cgi?id=500277) but it really
>> doesn't matter now.
>>
>

> Wait - are we talking about requiring SSE or SSE2? The thread up to this
> point was talking about requiring just SSE, not SSE2. I just want to make
> sure we're on the same page since according to mhoye's post the non-SSE2
> population is ~25x larger than the non-SSE population...
>
>
>>

>> We do need to avoid updating these users to a build that will crash, and
>> do the same "unsupported" messaging we're doing for old versions of MacOS.
>> Gregory, will you own that? You will probably need to add CPU feature
>> detection to the update URL/params for 47, or use some kind of system addon
>> to shunt these users off the main update path.
>>
>

> Given that 47 is in Beta, is it too late/risky to make this change on that
> channel? Should we revert to VS2013 on Aurora/48 and make the updater
> modifications on that channel? I think this will have minimal negative
> impact, as most of the impact to changing toolchains would be on central,
> as that is where most developers and automation live.
>
>
>>

>> On Fri, May 6, 2016 at 10:10 AM, Mike Hoye <mh...@mozilla.com> wrote:
>>
>>> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>>>
>>>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>>>> instructions. This instruction is part of the original SSE instruction
>>>> set,
>>>> which was initially unveiled by Intel on the Pentium 3 in 1999 and
>>>> later by
>>>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>>>> need
>>>> Firefox to run on processors manufactured in the 90s.
>>>>
>>> Per an IRC conversation with chutten, Firefox users on CPUs that do not
>>> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
>>> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
>>> etc), this work provides continuity of support to 0.01% of our users.
>>>
>>> - mhoye
>>>
>>>
>>> 09:59 <chutten> So, to put it clearly and precisely, of the Firefox
>>> Population in release and beta who are reporting at least base telemetry
>>> collection on machines running supported configurations, only 0.01% cannot
>>> definitively say they have SSE.
>>> 10:00 <chutten> (according to a 1% random sample as stored in the
>>> longitudinal dataset)
>>>

[Jim Blandy]

Since we didn't require SSE2 in 32-bit builds until this point, were
floating-point results rounded unpredictably in those builds until now?


On Fri, May 13, 2016 at 1:42 PM, Benjamin Smedberg <benj...@smedbergs.us>

[Henri Sivonen]

On Fri, May 13, 2016 at 11:42 PM, Benjamin Smedberg

<benj...@smedbergs.us> wrote:
> I am talking about requiring SSE2. That is a larger (but still quite small)
> population, but the upside of being able to turn on SSE2 optimizations by
> default is an important benefit. I've discussed and confirmed this with
> Firefox product management.
>
> So yes, the plan of record is to require SSE2 starting in Firefox 49, and I
> will update the tracking bugs to reflect that.

Excellent! Thank you! Yay for being able to use the vanilla Rust CPU
targeting config going forward.

For clarification: Does this decision apply to 32-bit x86 Linux as
well? (It would be sad to have to supply and maintain non-SSE2 x86
code paths just for Linux.)

On Wed, May 11, 2016 at 5:01 AM, Robert Strong <rst...@mozilla.com> wrote:
> The majority of this involves getting whether the CPU supports SSE. The app
> update part involves inserting the value into the url.
>

> Having said that, I've already started looking at this today. It would be
> good to know whether this info will be needed on other platforms at some
> point as well.

Regardless of what the answer is to the question above about requiring
SSE2 on Linux, it's safe to assume that the Linux updater, too, is
going to need to filter on SSE2 availability at some point.

[Benjamin Smedberg]

On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

>
>
> For clarification: Does this decision apply to 32-bit x86 Linux as
> well? (It would be sad to have to supply and maintain non-SSE2 x86
> code paths just for Linux.)
>

Nobody asked about that, so it's wasn't specifically included.

IIRC the Mozilla builds of Firefox for Linux already require SSE2 by virtue
of their -i686 build targeting, so the real question here is whether we
want to support distros that don't require SSE2? I'm ok with that, but I
don't whether there are distros who want to disagree or how I'd communicate
this more effectively.

--BDS

[Ralph Giles]

On Mon, May 16, 2016 at 10:53 AM, Benjamin Smedberg
<benj...@smedbergs.us> wrote:

> IIRC the Mozilla builds of Firefox for Linux already require SSE2 by virtue
> of their -i686 build targeting, so the real question here is whether we
> want to support distros that don't require SSE2? I'm ok with that, but I
> don't whether there are distros who want to disagree or how I'd communicate
> this more effectively.

It's also not clear how many of the distros which technically target
i[345]86 actually function on non-SSE2 hardware. It's easy for
non-compliant binaries to slip in if there's no active testing for
this.

-r

[Mike Hommey]

On Mon, May 16, 2016 at 01:53:51PM -0400, Benjamin Smedberg wrote:
> On Mon, May 16, 2016 at 8:47 AM, Henri Sivonen <hsiv...@hsivonen.fi>
> wrote:
>
> >
> >
> > For clarification: Does this decision apply to 32-bit x86 Linux as
> > well? (It would be sad to have to supply and maintain non-SSE2 x86
> > code paths just for Linux.)
> >
>
> Nobody asked about that, so it's wasn't specifically included.
>

> IIRC the Mozilla builds of Firefox for Linux already require SSE2 by
> virtue of their -i686 build targeting,

They don't. They explicitly target the pentiumpro arch.

Mike

[yuhong...@hotmail.com]

On Saturday, May 7, 2016 at 2:18:05 AM UTC-7, Emanuel Hoogeveen wrote:
> Well, I think that's debatable ;) The Athlon XP had clock speeds of up to 2333MHz, though I'm sure the per-clock performance doesn't measure up to current offerings. But Ion can easily be 5x as fast as Baseline. Of course, whether that makes a difference depends on what JS you're running. But either way, people with these processors are getting a double whammy of degraded performance.

I wonder how a Northwood Pentium 4 running Ion would compare with an Athlon XP running Baseline.