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.ch...@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 <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
