mbox series

[bug#61586,RFC,0/2] Add BinaryEn

Message ID 2cc4a1091e54c0fec082de4ce2789dfc42470e54.camel@gmail.com
Headers show
Series Add BinaryEn | expand

Message

Liliana Marie Prikler Feb. 17, 2023, 8:45 p.m. UTC 
Hi Guix,

this series gets us a little closer to having a "full" WebAssembly stack.
It packages binaryen, on top of which other compilers such as emscripten
or AssemblyScript (a sort of Typescript?) are built.

However, there is a grain of salt.  It appears binaryen has some rather
esoteric use for -msse2 on i686: Rather than performance, it wants it
for precision.  Needless to say, this would break compatibility with
older CPUs.  I'm wondering if we should simply drop i686 (and similarly
32-bit ARM) from supported-systems or whether there's a more clever
hack to use here.

Cheers

Liliana Marie Prikler (2):
  gnu: Add python-filecheck.
  gnu: Add binaryen.

 gnu/packages/check.scm | 25 +++++++++++++++++++++++
 gnu/packages/web.scm   | 45 ++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+)


base-commit: 312f1f41d3f3f3e5d2c36ff46920c6dce1c21a17

Comments

Andreas Enge March 11, 2023, 10:48 p.m. UTC | #1 
Hello Liliana,

how about you start by pushing the python-filecheck package?

Do you have a pointer to BinaryEn using -msse2 for precision?
I am not familiar with SSE2, but a quick look-up on Wikipedia only shows
(packed) double floating point operations and packed integer arithmetic.
All these should be feasible directly in C, although maybe more slowly.

In the CMakeLists.txt file there are the following lines:
  if(NOT EMSCRIPTEN)
    if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i.86$")
      # wasm doesn't allow for x87 floating point math
      add_compile_flag("-msse2")
      add_compile_flag("-mfpmath=sse")
    elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^armv[2-6]" AND NOT CMAKE_CXX_FLAGS MATCHES "-mfpu=")
      add_compile_flag("-mfpu=vfpv3")
    endif()
  endif()

So the -msse2 flag will not be added on arm; the package is compiled
successfully on aarch64, and I see no reason why in principal it should
not also work on armhf. Maybe there is a more precise test for x86_64
that could be used instead of
    if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i.86$") ?
Building on armhf and i686 currently fails (is "blocked" in QA parlance):
   https://qa.guix.gnu.org/issue/61586
due to python-aioredis failing on i686
   https://data.qa.guix.gnu.org/build-server/2/build?build_server_build_id=00818a34-5efe-4a73-8ca2-3e095885c7ee
and node, python-simplejson and python-numpy on armhf:
   https://data.qa.guix.gnu.org/build-server/2/build?build_server_build_id=34851d8f-41c9-4a8b-9150-3071e1a6d9f7

Andreas
Liliana Marie Prikler March 12, 2023, 8:16 a.m. UTC | #2 
Am Samstag, dem 11.03.2023 um 23:48 +0100 schrieb Andreas Enge:
> Hello Liliana,
Hi Andreas, please don't forget to add me in CC.

> how about you start by pushing the python-filecheck package?
I'd only do that if it has another user and for the time being I don't
see that.  Don't worry, I still got more python packages in my backlog
:)

> Do you have a pointer to BinaryEn using -msse2 for precision?
> I am not familiar with SSE2, but a quick look-up on Wikipedia only
> shows (packed) double floating point operations and packed integer
> arithmetic.
> All these should be feasible directly in C, although maybe more
> slowly.
Possible, but more slowly in C doesn't translate that nicely if you
don't want to code up your own float/double types and you really don't
want that.

The problem here is that expressions like:
  double a, b, c;
  c = sqrt(a * a, b * b);
can use 80 bit intermediaries on x87 chips, which they don't when using
SSE2 – hence the precision argument.  You would have to redefine all
basic operations for your floating point (which would still be doable
in C++ due to operator overloading, but be a major pain in the butt to
do correctly and well-tested, hence the deference to SSE2, I believe).

> In the CMakeLists.txt file there are the following lines:
>   if(NOT EMSCRIPTEN)
>     if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i.86$")
>       # wasm doesn't allow for x87 floating point math
>       add_compile_flag("-msse2")
>       add_compile_flag("-mfpmath=sse")
>     elseif(CMAKE_SYSTEM_PROCESSOR MATCHES "^armv[2-6]" AND NOT
> CMAKE_CXX_FLAGS MATCHES "-mfpu=")
>       add_compile_flag("-mfpu=vfpv3")
>     endif()
>   endif()
> 
> So the -msse2 flag will not be added on arm; the package is compiled
> successfully on aarch64, and I see no reason why in principal it
> should not also work on armhf. 
It does require the vfpv3 fpu, which I believe won't exist on all arms.

> Maybe there is a more precise test for x86_64 that could be used
> instead of
>     if(CMAKE_SYSTEM_PROCESSOR MATCHES "^i.86$") ?
Not for the kind of check they want to make, I believe.

Cheers
Andreas Enge March 12, 2023, 10:49 a.m. UTC | #3 
Hello,

Am Sun, Mar 12, 2023 at 09:16:45AM +0100 schrieb Liliana Marie Prikler:
> Am Samstag, dem 11.03.2023 um 23:48 +0100 schrieb Andreas Enge:
> > Hello Liliana,
> Hi Andreas, please don't forget to add me in CC.

ah, I thought that debbugs would automatically redispatch the mail
to everybody who contributed to the report.

> The problem here is that expressions like:
>   double a, b, c;
>   c = sqrt(a * a, b * b);
> can use 80 bit intermediaries on x87 chips, which they don't when using
> SSE2 – hence the precision argument.  You would have to redefine all
> basic operations for your floating point (which would still be doable
> in C++ due to operator overloading, but be a major pain in the butt to
> do correctly and well-tested, hence the deference to SSE2, I believe).

Hm, I thought that when using gcc and glibc, floating point operations
now followed the IEEE-754 standard. Then it would not matter what the
internal format is (except for special functions).

Still, I wonder if it would not be possible to change the configure test
so that the package compiles on 32 bit platforms; otherwise we would have
to take them out from the supported systems. And that would not be better
(assuming that the package passes its tests on these platforms, of course).

Andreas