Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Sun, 28 Jan 2024 19:26:46 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuCYsAhmdPTLKketpbvVv128zySzutvFqLqa91srWGBykQ@mail.gmail.com> |
--===============4757570664320263896==
Content-Type: multipart/alternative; boundary="000000000000d3105c06100d3780"
--000000000000d3105c06100d3780
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi,
I have one question regarding
pypy/module/_rawffi/alt/test/test_funcptr.py. In test_getaddressindll, the
test uses `sys.maxint*2 - 1` as the mask (on linux):
def test_getaddressindll(self):
import sys
from _rawffi.alt import CDLL
libm =3D CDLL(self.libm_name)
pow_addr =3D libm.getaddressindll('pow')
fff =3D sys.maxint*2-1 ### WHY??
if sys.platform =3D=3D 'win32' or sys.platform =3D=3D 'darwin':
fff =3D sys.maxint*2+1
assert pow_addr =3D=3D self.pow_addr & fff
But on Linux (both x86_64 and riscv), `sys.maxint*2 - 1` is
0xffffffff_fffffffd (or 0b1111_...._1111_1101). Why does the mask end with
0xd? It is a little weird because if the intention is to ensure the
address is aligned to multiple of 4, the mask should end with 0xc.
It is causing a problem for the RISC-V backend because in RISC-V the
function address can be multiple of 2.
# Other status updates
This week I ran the test suites (see results below). I fixed one error
related to large frame slot offsets (caught by test_tarfile).
* Test Suite: app-level (-A) test
* test_getsetsockopt_zero -- It looks like a buffer uninitialized error
(the second byte changes between runs) (untriaged)
* test_half_conversions -- No idea (untriaged)
* test_floorceiltrunc -- It looks like RISC-V floor/ceil/trunc don't
preserve signbit for nan inputs.
* test__mercurial -- It looks like I have to install git and rebuild a
pypy from scratch.
* Test Suite: -D tests
* All passes.
* Test Suite: extra tests
* test_connection_del - OperationalError: Could not open database
(untriaged)
* Test Suite: lib-python test
* test_ssl -- (untriaged)
* test_tokenize -- (untriaged)
* test_zipfile64 -- It looks like heap corruption (maybe related to bad
malloc_nursery fast path) (untriaged)
* Test Suite: pypyjit tests
* test_jitlogparser -- (untriaged)
* test_micronumpy -- (untriaged)
I also ran test_ll_random.py with `--repeat=3D20000 --random-seed=3D1234` a=
nd
all test are passing.
Regards,
Logan
On Mon, Jan 22, 2024 at 10:19=E2=80=AFPM Logan Chien <tzuhsiang.chien@gmail=
.com>
wrote:
> Hi Maciej
>
> Thank you for the information. It sounds like a good idea to run this
> before I go to sleep.
>
> Other updates:
>
> I didn't make progress last weekend. I spent last weekend revising the
> code generator for integer immediate load (replace up-to-eight-instructio=
ns
> with pc-relative load instructions). I will try them in the upcoming
> weekends.
>
> Regards,
> Logan
>
> On Sun, Jan 21, 2024 at 10:36=E2=80=AFPM Maciej Fijalkowski <fijall@gmail=
.com>
> wrote:
>
>> Hi Logan
>>
>> Additionally to what Matti says, there are random fuzzing tests like
>> test_ll_random.py in jit/backend/test. Run those for longer than the
>> default (e.g. whole night) to see if they find issues
>>
>> Best,
>> Maciej Fijalkowski
>>
>> On Tue, 16 Jan 2024 at 07:02, Logan Chien <[email protected]>
>> wrote:
>> >
>> > Hi,
>> >
>> > I have good news: the RISC-V backend can pass as many unit tests as th=
e
>> AArch64 backend. I got vmprof and codemap working this weekend. I also
>> completed a full translation and got a workable pypy executable.
>> >
>> > I have two questions now:
>> >
>> > 1. Are there other test suites that I can check for the correctness?
>> > 2. How do we measure the performance? Do we have a command line that
>> can run all benchmarks?
>> >
>> > Thank you in advance.
>> >
>> > Regards,
>> > Logan
>> >
>> > p.s. All changes are at: https://github.com/loganchien/pypy/tree/rv64
>> >
>> > On Mon, Jan 15, 2024 at 8:54=E2=80=AFPM Logan Chien <tzuhsiang.chien@g=
mail.com>
>> wrote:
>> >>
>> >> Hi Maciej,
>> >>
>> >> Thank you for your information. Let me conduct more surveys. Thanks=
.
>> >>
>> >> Regards,
>> >> Logan
>> >>
>> >> On Thu, Jan 11, 2024 at 2:44=E2=80=AFAM Maciej Fijalkowski <fijall@gm=
ail.com>
>> wrote:
>> >>>
>> >>> Hi Logan
>> >>>
>> >>> As far as I remember (and neither Armin nor I did any major pypy
>> >>> development recently), the vectorization was never really something =
we
>> >>> got to work to the point where it was worth it. In theory, having
>> >>> vectorized operations like numpy arrays to compile to vectorized CPU
>> >>> instructions would be glorious, but in practice it never worked well
>> >>> enough for us to enable it by default.
>> >>>
>> >>> Best,
>> >>> Maciej
>> >>>
>> >>> On Wed, 10 Jan 2024 at 08:39, Logan Chien <[email protected]=
>
>> wrote:
>> >>> >
>> >>> > Hi Armin,
>> >>> >
>> >>> > > About the V extension, I'm not sure it would be helpful; do you
>> plan
>> >>> > > to use it in the same way as our x86-64 vector extension
>> support? As
>> >>> > > far as I know this has been experimental all along and isn't
>> normally
>> >>> > > enabled in a standard PyPy. (I may be wrong about that.)
>> >>> >
>> >>> > Well, if the vector extension is not enabled by default even for
>> x86-64 backend, then I will have to conduct more survey, planning, and
>> designing. I haven't read the vectorization code yet.
>> >>> >
>> >>> > Anyway, I will finish the basic JIT first.
>> >>> >
>> >>> > Regards,
>> >>> > Logan
>> >>> >
>> >>> > On Tue, Jan 9, 2024 at 2:22=E2=80=AFAM Armin Rigo <armin.rigo@gmai=
l.com>
>> wrote:
>> >>> >>
>> >>> >> Hi Logan,
>> >>> >>
>> >>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <
>> [email protected]> wrote:
>> >>> >> > Currently, I only target RV64 IMAD:
>> >>> >> >
>> >>> >> > I - Base instruction set
>> >>> >> > M - Integer multiplication
>> >>> >> > A - Atomic (used by call_release_gil)
>> >>> >> > D - Double precision floating point arithmetic
>> >>> >> >
>> >>> >> > I don't use the C (compress) extension for now because it may
>> complicate the branch offset calculation and register allocation.
>> >>> >> >
>> >>> >> > I plan to support the V (vector) extension after I finish the
>> basic JIT support. But there are some unknowns. I am not sure whether =
(a)
>> I want to detect the availability of the V extension dynamically (thus
>> sharing the same pypy executable) or (b) build different executables for
>> different combinations of extensions. Also, I don't have a development
>> board that supports the V extension. I am searching for one.
>> >>> >> >
>> >>> >> > Another remote goal is to support RV32IMAF (singlefloats) or
>> RV32IMAD. In RISC-V, 32-bit and 64-bit ISAs are quite similar. The onl=
y
>> difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some special
>> instructions for 64-bit (e.g. ADDW). I isolated many of them into
>> load_int/store_int helper functions so that it will be easy to swap
>> implementations. However, I am not sure if we have to change the object
>> alignment in `malloc_nursery*` (to ensure we align to multiples of
>> `double`). Also, I am not sure whether it is common for RV32 cores to
>> include the D extension. But, anyway, RV32 will be a lower priority for=
me
>> because I will have to figure out how to build a RV32 root filesystem fi=
rst
>> (p.s. Debian doesn't (officially) support RV32 as of writing).
>> >>> >>
>> >>> >> Cool! Here are a few thoughts I had when I looked at some RISC-V
>> >>> >> early documents long ago (warning, it may be outdated):
>> >>> >>
>> >>> >> Yes, not using the "compress" extension is probably a good
>> approach.
>> >>> >> That looks like something a compiler might do, but it's quite a
>> bit of
>> >>> >> work both implementation-wise, and it's unclear if it would help
>> anyway here.
>> >>> >>
>> >>> >> About the V extension, I'm not sure it would be helpful; do you
>> plan
>> >>> >> to use it in the same way as our x86-64 vector extension support?
>> As
>> >>> >> far as I know this has been experimental all along and isn't
>> normally
>> >>> >> enabled in a standard PyPy. (I may be wrong about that.)
>> >>> >>
>> >>> >> Singlefloats: we don't do any arithmetic on singlefloats with the
>> JIT,
>> >>> >> but it has got a few instructions to pack/unpack double floats in=
to
>> >>> >> single floats or to call a C-compiled function with singlefloat
>> >>> >> arguments. That's not optional, though I admit I don't know how =
a
>> C
>> >>> >> compiler compiles these operations if floats are not supported by
>> the
>> >>> >> hardware. But as usual, you can just write a tiny C program and
>> see.
>> >>> >>
>> >>> >> I agree that RV32 can be a more remote goal for now. It should
>> >>> >> simplify a lot of stuff if you can just assume a 64-bit
>> environment.
>> >>> >> Plus all the other points you mention: the hardware may not suppo=
rt
>> >>> >> doubles, and may not be supported by Debian...
>> >>> >>
>> >>> >>
>> >>> >> A bient=C3=B4t,
>> >>> >>
>> >>> >> Armin Rigo
>> >>> >
>> >>> > _______________________________________________
>> >>> > pypy-dev mailing list -- [email protected]
>> >>> > To unsubscribe send an email to [email protected]
>> >>> > https://mail.python.org/mailman3/lists/pypy-dev.python.org/
>> >>> > Member address: [email protected]
>>
>
--000000000000d3105c06100d3780
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I have one question rega=
rding pypy/module/_rawffi/alt/test/test_funcptr.py.=C2=A0 In test_getaddres=
sindll, the test uses `sys.maxint*2 - 1` as the mask (on linux):</div><div>=
<br>=C2=A0 =C2=A0 def test_getaddressindll(self):<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 import sys<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 from _rawffi.alt import CD=
LL<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 libm =3D CDLL(self.libm_name)<br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 pow_addr =3D libm.getaddressindll('pow')<br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 fff =3D sys.maxint*2-1=C2=A0=C2=A0=C2=A0 ### WH=
Y??<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 if sys.platform =3D=3D 'win32' o=
r sys.platform =3D=3D 'darwin':<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 fff =3D sys.maxint*2+1<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 assert pow=
_addr =3D=3D self.pow_addr & fff</div><div><br></div><div>But on Linux =
(both x86_64 and riscv), `sys.maxint*2 - 1` is 0xffffffff_fffffffd (or 0b11=
11_...._1111_1101).=C2=A0 Why does the mask end with 0xd?=C2=A0 It is a lit=
tle weird because if the intention is to ensure the address is aligned to m=
ultiple of 4, the mask should end with 0xc.</div><div><br></div><div>It is =
causing a problem for the RISC-V backend because in RISC-V the function add=
ress can be multiple of 2.</div><div><br></div><div><br></div><div># Other =
status updates</div><div><br></div><div>This week I ran the test suites (se=
e results below).=C2=A0 I fixed one error related to large frame slot offse=
ts (caught by test_tarfile).</div><div><br></div><div>* Test Suite: app-lev=
el (-A) test <br>=C2=A0 * test_getsetsockopt_zero -- It looks like a buffer=
uninitialized error (the second byte changes between runs) (untriaged)<br>=
=C2=A0 * test_half_conversions -- No idea (untriaged)<br>=C2=A0 * test_floo=
rceiltrunc -- It looks like RISC-V floor/ceil/trunc don't preserve sign=
bit for nan inputs.<br>=C2=A0 * test__mercurial -- It looks like I have to =
install git and rebuild a pypy from scratch.<br>* Test Suite: -D tests<br>=
=C2=A0 * All passes.<br>* Test Suite: extra tests<br>=C2=A0 * test_connecti=
on_del - OperationalError: Could not open database (untriaged)<br>* Test Su=
ite: lib-python test <br>=C2=A0 * test_ssl -- (untriaged)<br>=C2=A0 * test_=
tokenize -- (untriaged)<br>=C2=A0 * test_zipfile64 -- It looks like heap co=
rruption (maybe related to bad malloc_nursery fast path) (untriaged)<br>* T=
est Suite: pypyjit tests<br>=C2=A0 * test_jitlogparser -- (untriaged)<br>=
=C2=A0 * test_micronumpy -- (untriaged)</div><div><br></div><div>I also ran=
test_ll_random.py with `--repeat=3D20000 --random-seed=3D1234` and all tes=
t are passing.<br></div><div><br></div><div>Regards,</div><div>Logan<br></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Mon, Jan 22, 2024 at 10:19=E2=80=AFPM Logan Chien <<a href=3D"mail=
to:[email protected]" target=3D"_blank">[email protected]</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>Hi Maciej</div><div><br></div><div>Thank you for the in=
formation.=C2=A0 It sounds like a good idea to run this before I go to slee=
p.</div><div><br></div><div>Other updates:</div><div><br></div><div>I didn&=
#39;t make progress last weekend.=C2=A0 I spent last weekend revising the c=
ode generator for integer immediate load (replace up-to-eight-instructions =
with pc-relative load instructions).=C2=A0 I will try them in the upcoming =
weekends.<br></div><div><br></div><div>Regards,</div><div>Logan<br></div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
Sun, Jan 21, 2024 at 10:36=E2=80=AFPM Maciej Fijalkowski <<a href=3D"ma=
ilto:[email protected]" target=3D"_blank">[email protected]</a>> wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Logan<br>
<br>
Additionally to what Matti says, there are random fuzzing tests like<br>
test_ll_random.py in jit/backend/test. Run those for longer than the<br>
default (e.g. whole night) to see if they find issues<br>
<br>
Best,<br>
Maciej Fijalkowski<br>
<br>
On Tue, 16 Jan 2024 at 07:02, Logan Chien <<a href=3D"mailto:tzuhsiang.c=
[email protected]" target=3D"_blank">[email protected]</a>> wrote:<=
br>
><br>
> Hi,<br>
><br>
> I have good news: the RISC-V backend can pass as many unit tests as th=
e AArch64 backend.=C2=A0 I got vmprof and codemap working this weekend.=C2=
=A0 I also completed a full translation and got a workable pypy executable.=
<br>
><br>
> I have two questions now:<br>
><br>
> 1. Are there other test suites that I can check for the correctness?<b=
r>
> 2. How do we measure the performance?=C2=A0 Do we have a command line =
that can run all benchmarks?<br>
><br>
> Thank you in advance.<br>
><br>
> Regards,<br>
> Logan<br>
><br>
> p.s. All changes are at: <a href=3D"https://github.com/loganchien/pypy=
/tree/rv64" rel=3D"noreferrer" target=3D"_blank">https://github.com/loganch=
ien/pypy/tree/rv64</a><br>
><br>
> On Mon, Jan 15, 2024 at 8:54=E2=80=AFPM Logan Chien <<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]<=
/a>> wrote:<br>
>><br>
>> Hi Maciej,<br>
>><br>
>> Thank you for your information.=C2=A0 Let me conduct more surveys.=
=C2=A0 Thanks.<br>
>><br>
>> Regards,<br>
>> Logan<br>
>><br>
>> On Thu, Jan 11, 2024 at 2:44=E2=80=AFAM Maciej Fijalkowski <<a =
href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>>=
wrote:<br>
>>><br>
>>> Hi Logan<br>
>>><br>
>>> As far as I remember (and neither Armin nor I did any major py=
py<br>
>>> development recently), the vectorization was never really some=
thing we<br>
>>> got to work to the point where it was worth it. In theory, hav=
ing<br>
>>> vectorized operations like numpy arrays to compile to vectoriz=
ed CPU<br>
>>> instructions would be glorious, but in practice it never worke=
d well<br>
>>> enough for us to enable it by default.<br>
>>><br>
>>> Best,<br>
>>> Maciej<br>
>>><br>
>>> On Wed, 10 Jan 2024 at 08:39, Logan Chien <<a href=3D"mailt=
o:[email protected]" target=3D"_blank">[email protected]</a=
>> wrote:<br>
>>> ><br>
>>> > Hi Armin,<br>
>>> ><br>
>>> > > About the V extension, I'm not sure it would be =
helpful; do you plan<br>
>>> > > to use it in the same way as our x86-64 vector exten=
sion support?=C2=A0 As<br>
>>> > > far as I know this has been experimental all along a=
nd isn't normally<br>
>>> > > enabled in a standard PyPy.=C2=A0 (I may be wrong ab=
out that.)<br>
>>> ><br>
>>> > Well, if the vector extension is not enabled by default e=
ven for x86-64 backend, then I will have to conduct more survey, planning, =
and designing.=C2=A0 I haven't read the vectorization code yet.<br>
>>> ><br>
>>> > Anyway, I will finish the basic JIT first.<br>
>>> ><br>
>>> > Regards,<br>
>>> > Logan<br>
>>> ><br>
>>> > On Tue, Jan 9, 2024 at 2:22=E2=80=AFAM Armin Rigo <<a =
href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
</a>> wrote:<br>
>>> >><br>
>>> >> Hi Logan,<br>
>>> >><br>
>>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <<a href=
=3D"mailto:[email protected]" target=3D"_blank">tzuhsiang.chien@gma=
il.com</a>> wrote:<br>
>>> >> > Currently, I only target RV64 IMAD:<br>
>>> >> ><br>
>>> >> > I - Base instruction set<br>
>>> >> > M - Integer multiplication<br>
>>> >> > A - Atomic (used by call_release_gil)<br>
>>> >> > D - Double precision floating point arithmetic<b=
r>
>>> >> ><br>
>>> >> > I don't use the C (compress) extension for n=
ow because it may complicate the branch offset calculation and register all=
ocation.<br>
>>> >> ><br>
>>> >> > I plan to support the V (vector) extension after=
I finish the basic JIT support.=C2=A0 But there are some unknowns.=C2=A0 I=
am not sure whether (a) I want to detect the availability of the V extensi=
on dynamically (thus sharing the same pypy executable) or (b) build differe=
nt executables for different combinations of extensions.=C2=A0 Also, I don&=
#39;t have a development board that supports the V extension.=C2=A0 I am se=
arching for one.<br>
>>> >> ><br>
>>> >> > Another remote goal is to support RV32IMAF (sing=
lefloats) or RV32IMAD.=C2=A0 In RISC-V, 32-bit and 64-bit ISAs are quite si=
milar.=C2=A0 The only difference is on LW/SW (32-bit) vs. LD/SD (64-bit) an=
d some special instructions for 64-bit (e.g. ADDW).=C2=A0 I isolated many o=
f them into load_int/store_int helper functions so that it will be easy to =
swap implementations.=C2=A0 However, I am not sure if we have to change the=
object alignment in `malloc_nursery*` (to ensure we align to multiples of =
`double`).=C2=A0 Also, I am not sure whether it is common for RV32 cores to=
include the D extension.=C2=A0 But, anyway, RV32 will be a lower priority =
for me because I will have to figure out how to build a RV32 root filesyste=
m first (p.s. Debian doesn't (officially) support RV32 as of writing).<=
br>
>>> >><br>
>>> >> Cool!=C2=A0 Here are a few thoughts I had when I look=
ed at some RISC-V<br>
>>> >> early documents long ago (warning, it may be outdated=
):<br>
>>> >><br>
>>> >> Yes, not using the "compress" extension is =
probably a good approach.<br>
>>> >> That looks like something a compiler might do, but it=
's quite a bit of<br>
>>> >> work both implementation-wise, and it's unclear i=
f it would help anyway here.<br>
>>> >><br>
>>> >> About the V extension, I'm not sure it would be h=
elpful; do you plan<br>
>>> >> to use it in the same way as our x86-64 vector extens=
ion support?=C2=A0 As<br>
>>> >> far as I know this has been experimental all along an=
d isn't normally<br>
>>> >> enabled in a standard PyPy.=C2=A0 (I may be wrong abo=
ut that.)<br>
>>> >><br>
>>> >> Singlefloats: we don't do any arithmetic on singl=
efloats with the JIT,<br>
>>> >> but it has got a few instructions to pack/unpack doub=
le floats into<br>
>>> >> single floats or to call a C-compiled function with s=
inglefloat<br>
>>> >> arguments.=C2=A0 That's not optional, though I ad=
mit I don't know how a C<br>
>>> >> compiler compiles these operations if floats are not =
supported by the<br>
>>> >> hardware.=C2=A0 But as usual, you can just write a ti=
ny C program and see.<br>
>>> >><br>
>>> >> I agree that RV32 can be a more remote goal for now.=
=C2=A0 It should<br>
>>> >> simplify a lot of stuff if you can just assume a 64-b=
it environment.<br>
>>> >> Plus all the other points you mention: the hardware m=
ay not support<br>
>>> >> doubles, and may not be supported by Debian...<br>
>>> >><br>
>>> >><br>
>>> >> A bient=C3=B4t,<br>
>>> >><br>
>>> >> Armin Rigo<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > pypy-dev mailing list -- <a href=3D"mailto:pypy-dev@pytho=
n.org" target=3D"_blank">[email protected]</a><br>
>>> > To unsubscribe send an email to <a href=3D"mailto:pypy-de=
[email protected]" target=3D"_blank">[email protected]</a><br>
>>> > <a href=3D"https://mail.python.org/mailman3/lists/pypy-de=
v.python.org/" rel=3D"noreferrer" target=3D"_blank">https://mail.python.org=
/mailman3/lists/pypy-dev.python.org/</a><br>
>>> > Member address: <a href=3D"mailto:[email protected]" targe=
t=3D"_blank">[email protected]</a><br>
</blockquote></div>
</blockquote></div>
--000000000000d3105c06100d3780--
--===============4757570664320263896==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
pypy-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/pypy-dev.python.org/
Member address: [email protected]
--===============4757570664320263896==--