Hi Armin,
Thank you for the reply. I'll check (1) the config, (2) the frontend code
that emits guard_not_invalidated, and (3) the actual performance on HW this
weekend.
Regards,
Logan
On Thu, Feb 29, 2024 at 4:45 AM Armin Rigo wrote:
> Hi Logan,
>
> On Thu, 29 Feb 2024 at 08:37, Logan Chien
Hi Logan,
On Thu, 29 Feb 2024 at 08:37, Logan Chien wrote:
> IIUC, the difference is that guard_not_invalidated is at a different location.
>
> But I don't understand why the backend can affect the logs in the
> 'jit-log-opt-' tag.
There are a few ways to influence the front-end: for example,
Hi all,
I am looking into the last failing case:
"TestMicroNumPy::()::test_reduce_logical_and" but I don't quite understand
what this test means.
The test case fails with:
```
Loops don't match
=
loop id = None
('operation mismatch',)
Hi Armin,
Thank you for the reply.
Luckily, I found the bug. It was a bug in my write barrier card marking
implementation. I misunderstood what AArch64 MVN instruction meant when I
was porting the code. After fixing it, I can pass these two test cases
(test_zipfile64 and test_tokenize).
Now,
Hi Logan,
On Tue, 20 Feb 2024 at 05:08, Logan Chien wrote:
> > This should just be #defined to do nothing with Boehm, maybe in
> > rpython/translator/c/src/mem.h
>
> With this change and a few RISC-V backend fixes (related to
> self.cpu.vtable_offset), I can build and run a JIT+BoehmGC PyPy.
Hi Armin,
Thank you for the reply.
> This should just be #defined to do nothing with Boehm, maybe in
rpython/translator/c/src/mem.h
With this change and a few RISC-V backend fixes (related to
self.cpu.vtable_offset), I can build and run a JIT+BoehmGC PyPy.
This configuration (JIT+BoehmGC) can
Hi Logan,
On Mon, 19 Feb 2024 at 05:02, Logan Chien wrote:
> 2890 | OP_GC_INCREASE_ROOT_STACK_DEPTH(l_v498959, /* nothing
> */);
Ah, yet another missing macro. This should just be #defined to do
nothing with Boehm, maybe in rpython/translator/c/src/mem.h in the
section "dummy
Hi Armin,
Thank you for your reply.
> Try to translate with the option ``--withoutmod-cpyext``.
This option fixes the error, but now I encounter another error message (in
pypy_module_sys.c):
```
pypy_module_sys.c: In function 'pypy_g_setrecursionlimit':
Hi Logan,
On Fri, 16 Feb 2024 at 07:46, Logan Chien wrote:
> pypy_module_cpyext.c:125333:80: error: expected expression before ')'
> token
> 125333 | OP_GC_RAWREFCOUNT_CREATE_LINK_PYOBJ(l_v451927,
> l_v451928, /* nothing */);
Ah, I guess that we are missing a
Hi all,
I wonder if there are any tricks that can be used to debug memory
corruption?
I am debugging test_tokenize and test_zipfile64 (from lib_python_tests.py).
If I run test_zipfile64, I sometimes see this error backtrace:
```
testMoreThan64kFilesAppend (test.test_zipfile64.OtherTests) ...
Hi CF,
Thank you for your reply.
>> I also ran test_ll_random.py with `--repeat=2 --random-seed=1234`
>> and all test are passing.
>
> How long does that take, in wall clock time? I think for the other
> backends we kept it running for a bunch of days after the last crash
> occurred.
It
On 1/29/24 09:27, CF Bolz-Tereick via pypy-dev wrote:
This test looks just wrong, in my opinion. Given that the variable name
is `fff`, I think it was just meant as a check "does it roughly look
like a pointer". So I think somebody just forgot that sys.maxint is not
a power of 2 (and then things
Hi Logan,
I wanted to start by stressing that this is really impressive progress.
We've never had get so far with a new backend without serious support by
the core JIT devs, so thanks a lot for your work, I'm really excited
about this!
A general suggestion about the test failures: for the
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)
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
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 wrote:
>
> Hi,
>
> I have
Hi Matti,
Thank you for your information. I will try these this weekend.
Regards,
Logan
On Tue, Jan 16, 2024, 12:52 AM Matti Picus wrote:
> On 16/1/24 07:02, Logan Chien wrote:
>
> > Hi,
> >
> > I have good news: the RISC-V backend can pass as many unit tests as
> > the AArch64 backend. I
On 16/1/24 07:02, Logan Chien 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
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
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 wrote:
> Hi Logan
>
> As far as I remember (and neither Armin nor I did any major pypy
> development recently), the vectorization was never
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
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
Hi Logan,
On Tue, 9 Jan 2024 at 04:01, Logan Chien 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
Hi,
> I have not taken any looks at all, but can you tell me what kind of setup
does one need for testing it? Are you using real hardware or emulation?
Currently, I use "qemu-user-static + schroot + Debian riscv64 root
filesystem" on an x86-64 host.
I have a HiFive Unmatched board as well. But
On 8/1/24 10:03, Maciej Fijalkowski wrote:
Hi Logan
Very cool you are interested in that! It's often useful to hang out on
IRC as you can ask questions directly. I have not taken any looks at
all, but can you tell me what kind of setup does one need for testing
it? Are you using real hardware
Hi Logan
Very cool you are interested in that! It's often useful to hang out on
IRC as you can ask questions directly. I have not taken any looks at
all, but can you tell me what kind of setup does one need for testing
it? Are you using real hardware or emulation?
The approach of starting with
Hi,
I forgot to include the link in my previous email.
If you want to have a look on my prototype, you can find it here:
https://github.com/loganchien/pypy/tree/rv64
Thanks.
Regards,
Logan
On Sun, Jan 7, 2024 at 5:18 PM Logan Chien
wrote:
> Hi all,
>
> I would like to contribute a RISC-V
27 matches
Mail list logo
