Re: Contribute a RISC-V 64 JIT backend
Logan Chien <[email protected]> Mon, 15 Jan 2024 20:54:06 -0800
| Newsgroups | gmane.comp.python.pypy |
|---|---|
| Message-ID | <CALQyFuCve_98bvT4bDB9n59YYHMomCDr69yMb0AF-8SzvXLLPA@mail.gmail.com> |
--===============2693878883829268341== Content-Type: multipart/alternative; boundary="000000000000343203060f08eca8" --000000000000343203060f08eca8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 <[email protected]= m> 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 <[email protected]= > 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 only > 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 fir= st > (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 anywa= y > 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 into > >> 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 support > >> 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] > --000000000000343203060f08eca8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>Hi Maciej,</div><div><br></div><div>Thank you for you= r information.=C2=A0 Let me conduct more surveys.=C2=A0 Thanks.</div><div><= br></div><div>Regards,</div><div>Logan<br></div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 11, 2024 at 2:4= 4=E2=80=AFAM Maciej Fijalkowski <<a href=3D"mailto:[email protected]">fij= [email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= ng-left:1ex">Hi Logan<br> <br> As far as I remember (and neither Armin nor I did any major pypy<br> development recently), the vectorization was never really something we<br> got to work to the point where it was worth it. In theory, having<br> vectorized operations like numpy arrays to compile to vectorized CPU<br> instructions would be glorious, but in practice it never worked 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"mailto:tzuhsiang.c= [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 y= ou plan<br> > > to use it in the same way as our x86-64 vector extension support?= =C2=A0 As<br> > > far as I know this has been experimental all along and isn't = normally<br> > > enabled in a standard PyPy.=C2=A0 (I may be wrong about that.)<br= > ><br> > Well, if the vector extension is not enabled by default even for x86-6= 4 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"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>> wrot= e:<br> >><br> >> Hi Logan,<br> >><br> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <<a href=3D"mailto:tzu= [email protected]" target=3D"_blank">[email protected]</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<br> >> ><br> >> > I don't use the C (compress) extension for now because it= may complicate the branch offset calculation and register allocation.<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 extension dynamicall= y (thus sharing the same pypy executable) or (b) build different executable= s for different combinations of extensions.=C2=A0 Also, I don't have a = development board that supports the V extension.=C2=A0 I am searching for o= ne.<br> >> ><br> >> > Another remote goal is to support RV32IMAF (singlefloats) or = RV32IMAD.=C2=A0 In RISC-V, 32-bit and 64-bit ISAs are quite similar.=C2=A0 = The only difference is on LW/SW (32-bit) vs. LD/SD (64-bit) and some specia= l instructions for 64-bit (e.g. ADDW).=C2=A0 I isolated many of them into l= oad_int/store_int helper functions so that it will be easy to swap implemen= tations.=C2=A0 However, I am not sure if we have to change the object align= ment 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 becaus= e I will have to figure out how to build a RV32 root filesystem 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 looked at some RI= SC-V<br> >> early documents long ago (warning, it may be outdated):<br> >><br> >> Yes, not using the "compress" extension is probably a go= od 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 if it would he= lp anyway here.<br> >><br> >> About the V extension, I'm not sure it would be helpful; do yo= u plan<br> >> to use it in the same way as our x86-64 vector extension support?= =C2=A0 As<br> >> far as I know this has been experimental all along and isn't n= ormally<br> >> enabled in a standard PyPy.=C2=A0 (I may be wrong about that.)<br> >><br> >> Singlefloats: we don't do any arithmetic on singlefloats with = the JIT,<br> >> but it has got a few instructions to pack/unpack double floats int= o<br> >> single floats or to call a C-compiled function with singlefloat<br= > >> arguments.=C2=A0 That's not optional, though I admit 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 tiny C program = and see.<br> >><br> >> I agree that RV32 can be a more remote goal for now.=C2=A0 It shou= ld<br> >> simplify a lot of stuff if you can just assume a 64-bit environmen= t.<br> >> Plus all the other points you mention: the hardware may not suppor= t<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:[email protected]" target= =3D"_blank">[email protected]</a><br> > To unsubscribe send an email to <a href=3D"mailto:pypy-dev-leave@pytho= n.org" target=3D"_blank">[email protected]</a><br> > <a href=3D"https://mail.python.org/mailman3/lists/pypy-dev.python.org/= " rel=3D"noreferrer" target=3D"_blank">https://mail.python.org/mailman3/lis= ts/pypy-dev.python.org/</a><br> > Member address: <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> </blockquote></div> --000000000000343203060f08eca8-- --===============2693878883829268341== 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] --===============2693878883829268341==--