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 = CDLL(self.libm_name) pow_addr = libm.getaddressindll('pow') fff = sys.maxint*2-1 ### WHY?? if sys.platform == 'win32' or sys.platform == 'darwin': fff = sys.maxint*2+1 assert pow_addr == 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=20000 --random-seed=1234` and all test are passing. Regards, Logan On Mon, Jan 22, 2024 at 10:19 PM 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-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 <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 <tzuhsiang.chien@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.chien@gmail.com>
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 <fijall@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.chien@gmail.com>
wrote:
Hi Armin,
> About the V extension, I'm not sure it would be helpful; do you
> 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.rigo@gmail.com> wrote: > > Hi Logan, > > On Tue, 9 Jan 2024 at 04:01, Logan Chien < tzuhsiang.chien@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
> 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
wrote: plan plan 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-leave@python.org https://mail.python.org/mailman3/lists/pypy-dev.python.org/ Member address: fijall@gmail.com