Re: Contribute a RISC-V 64 JIT backend

--===============4646954841135274404==
Content-Type: multipart/alternative; boundary="000000000000a7679b0611f2201f"

--000000000000a7679b0611f2201f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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, I am looking into test_json.  Earlier, I thought it was an XFAIL
because the -O2 build was failing too.  But after adding
`@settings(suppress_health_check=3D[HealthCheck.too_slow])` to
`test_json.test_roundtrip`, I could run it in reasonable time.

However, it was extremely slow when I ran the same test with the `-Ojit`
build.  According to `PYPYLOG=3Djit:log.txt`, the JIT compiler kept buildin=
g
the same (or similar) bridge.  Statistics showed that the RISC-V JIT
compiled more than 3000 bridges (when Ctrl-C interrupted) whereas the X86
JIT build compiled only 900 bridges (when completed).  I will try to figure
out the failing guard op first.

Regards,
Logan

On Mon, Feb 19, 2024 at 10:05=E2=80=AFPM Armin Rigo <[email protected]> =
wrote:

> Hi Logan,
>
> On Tue, 20 Feb 2024 at 05:08, Logan Chien <[email protected]>
> 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.
>
> Cool!  I also got a pull request merged into the main branch with this
> change, and it does indeed fix boehm builds.
>
> > This configuration (JIT+BoehmGC) can pass test_tokenize and
> test_zipfile64 (from lib_python_tests.py).
> >
> > Thus, my next step will focus on the differences between JIT+BoehmGC an=
d
> JIT+IncminimarkGC.
>
> A problem that came up a lot in other backends is a specific input
> instruction that the backend emits with specific registers.  When you
> run into the bad case, the emitted code reuses a register *before*
> reading the same register assuming that it still contains its old
> value.  It's entirely dependent on register allocation, and if you run
> it with boehm then the sequence of instruction is slightly different
> and that might be the reason that the bug doesn't show up then.  If
> you get two failures with incminimark and none with boehm, then it
> sounds more likely that the case involves one of the incminimark-only
> constructions---but it's also possible the bug is somewhere unrelated
> and it's purely bad luck...
>
>
> Armin
>

--000000000000a7679b0611f2201f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Armin,</div><div><br></div><div>Thank you for the =
reply.</div><div><br></div><div>Luckily, I found the bug.=C2=A0 It was a bu=
g in my write barrier card marking implementation.=C2=A0 I misunderstood wh=
at AArch64 MVN instruction meant when I was porting the code.=C2=A0 After f=
ixing it, I can pass these two test cases (test_zipfile64 and test_tokenize=
).</div><div><br></div><div>Now, I am looking into test_json.=C2=A0 Earlier=
, I thought it was an XFAIL because the -O2 build was failing too.=C2=A0 Bu=
t after adding `@settings(suppress_health_check=3D[HealthCheck.too_slow])` =
to `test_json.test_roundtrip`, I could run it in reasonable time.</div><div=
><br></div><div>However, it was extremely slow when I ran the same test wit=
h the `-Ojit` build.=C2=A0 According to `PYPYLOG=3Djit:log.txt`, the JIT co=
mpiler kept building the same (or similar) bridge.=C2=A0 Statistics showed =
that the RISC-V JIT compiled more than 3000 bridges (when Ctrl-C interrupte=
d) whereas the X86 JIT build compiled only 900 bridges (when completed).=C2=
=A0 I will try to figure out the failing guard op first.</div><div><br></di=
v><div>Regards,</div><div>Logan<br></div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 19, 2024 at 10:05=E2=
=80=AFPM Armin Rigo &lt;<a href=3D"mailto:[email protected]">armin.rigo@=
gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">Hi Logan,<br>
<br>
On Tue, 20 Feb 2024 at 05:08, Logan Chien &lt;<a href=3D"mailto:tzuhsiang.c=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<=
br>
&gt; &gt; This should just be #defined to do nothing with Boehm, maybe in r=
python/translator/c/src/mem.h<br>
&gt;<br>
&gt; With this change and a few RISC-V backend fixes (related to self.cpu.v=
table_offset), I can build and run a JIT+BoehmGC PyPy.<br>
<br>
Cool!=C2=A0 I also got a pull request merged into the main branch with this=
<br>
change, and it does indeed fix boehm builds.<br>
<br>
&gt; This configuration (JIT+BoehmGC) can pass test_tokenize and test_zipfi=
le64 (from lib_python_tests.py).<br>
&gt;<br>
&gt; Thus, my next step will focus on the differences between JIT+BoehmGC a=
nd JIT+IncminimarkGC.<br>
<br>
A problem that came up a lot in other backends is a specific input<br>
instruction that the backend emits with specific registers.=C2=A0 When you<=
br>
run into the bad case, the emitted code reuses a register *before*<br>
reading the same register assuming that it still contains its old<br>
value.=C2=A0 It&#39;s entirely dependent on register allocation, and if you=
 run<br>
it with boehm then the sequence of instruction is slightly different<br>
and that might be the reason that the bug doesn&#39;t show up then.=C2=A0 I=
f<br>
you get two failures with incminimark and none with boehm, then it<br>
sounds more likely that the case involves one of the incminimark-only<br>
constructions---but it&#39;s also possible the bug is somewhere unrelated<b=
r>
and it&#39;s purely bad luck...<br>
<br>
<br>
Armin<br>
</blockquote></div>

--000000000000a7679b0611f2201f--

--===============4646954841135274404==
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]

--===============4646954841135274404==--