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-instructions with pc-relative load instructions). I will try them in the upcoming weekends. Regards, Logan On Sun, Jan 21, 2024 at 10:36 PM Maciej Fijalkowski <fij...@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 <tzuhsiang.ch...@gmail.com> > wrote: > > > > Hi, > > > > I have good news: the RISC-V backend can pass as many unit tests as the > 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 PM Logan Chien <tzuhsiang.ch...@gmail.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 AM Maciej Fijalkowski <fij...@gmail.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 <tzuhsiang.ch...@gmail.com> > 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 AM Armin Rigo <armin.r...@gmail.com> > wrote: > >>> >> > >>> >> Hi Logan, > >>> >> > >>> >> On Tue, 9 Jan 2024 at 04:01, Logan Chien <tzuhsiang.ch...@gmail.com> > 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 first > (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 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ôt, > >>> >> > >>> >> Armin Rigo > >>> > > >>> > _______________________________________________ > >>> > pypy-dev mailing list -- pypy-dev@python.org > >>> > To unsubscribe send an email to pypy-dev-le...@python.org > >>> > https://mail.python.org/mailman3/lists/pypy-dev.python.org/ > >>> > Member address: fij...@gmail.com >
_______________________________________________ pypy-dev mailing list -- pypy-dev@python.org To unsubscribe send an email to pypy-dev-le...@python.org https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: arch...@mail-archive.com
