On Thu, Jun 27, 2019 at 03:26:32PM +0300, Adrian Bunk wrote:

> > We like to support non-sse2 on i386, but we are not comfortable
> > fixing webkit2gtk at this stage of the release.
> Why is this relatively small change a problem in a package where new
> upstream versions are permitted after the release of stable?

I'll try to explain again with more detail so we all understand the
nature of the proposed changes.

- WebKitGTK has several mechanisms to run JavaScript code, in brief: a
  C-based interpreter (CLoop), an assembler-based interpreter and a
  JIT compiler.

- CLoop is the slowest but it is portable and runs in all platforms.
  It's the one selected at build time when the CPU is unsupported or

- The other two generate CPU-specific code. In an effort to simplify
  them upstream took recently the decision to stop supporting i386
  processors without SSE2 instructions.

- Because of that, WebKitGTK 2.24.1 added a build-time check to detect
  if the compiler can generate SSE2 instructions. For the Debian case
  I had to add -msse2 -mfpmath=sse to CFLAGS, as suggested by

- The consequence of this is that GCC generates SSE2 instructions when
  appropriate when compiling regular C/C++ code, causing crashes like
  the one previously reported.

- However, and this is the part that I originally overlooked, only the
  C-based interpreter is working at the moment in i386. The other two
  are less actively maintained for i386, and stopped working after
  some big changes upstream in the last few months.
- So it is possible to remove the compile-time check for SSE2 and
  build the package without those flags in i386.

What this all means is that the only real difference between
webkit2gtk 2.24.2-1 (in buster) and 2.24.2-2 (in sid) is that, for
i386, the former is compiled with -msse2 -mfpmath=sse and the latter
is not. So for floating point operations the former uses SSE2 and the
latter uses x87. This produces some differences in rounding in some
corner cases which could have user-visible consequences.

We don't know when it is going to happen, but once upstream brings
back JIT support to i386 again we would have to make the decision to

 a) keep using CLoop in order to remain compatible with non-SSE2 CPUs
    (conservative approach, I'd probably support this one).
 b) think of a way to support both sets of users so those with more
    modern processors can benefit from the additional performance of
    the JIT compiler. This could involve using e.g. /usr/lib/sse2/ for
    those binaries.

I hope this clarifies the situation.


Reply via email to