Re: Contribute a RISC-V 64 JIT backend

--===============8967805982664191151==
Content-Type: multipart/alternative; boundary="0000000000008c84b906129eb81d"

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

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=E2=80=AFAM Armin Rigo <[email protected]> w=
rote:

> Hi Logan,
>
> On Thu, 29 Feb 2024 at 08:37, Logan Chien <[email protected]>
> 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, the
> "support_*" class-level flags.  Maybe the front-end did either do or
> skip a specific optimization when compared with x86, and it results
> only in a 'guard_not_invalidated' being present or not (and then once
> it is emitted, it's not emitted again a few instructions below).  Or
> there are some other reasons.  But as a general rule, we can mostly
> ignore the position of 'guard_not_invalidated'.  It should have no
> effect except in corner cases.
>
> > Also, I found that reduce_logical_and (failed) and reduce_logical_xor
> (passed) are very different.
> >
> > Is there more information on the details of this test?  Any ideas to
> debug this test case are very welcomed!  Thanks.
>
> A possibility is that some of these tests are flaky in the sense of
> passing half by chance on x86---I vaguely remember having some
> troubles sometimes.  It's sometimes hard to write tests without
> testing too many details.  Others may have better comments about them.
> Generally, it's OK to look at what you got and compare it with what
> the test expects.  If you can come up with a reason for why what you
> got is correct too, and free of real performance issues, then that's
> good enough.
>
> A bient=C3=B4t,
> Armin
>

--0000000000008c84b906129eb81d
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.=C2=A0 I&#39;ll check (1) the config, (2) the frontend code that emit=
s guard_not_invalidated, and (3) the actual performance on HW this weekend.=
</div><div><br></div><div>Regards,</div><div>Logan<br></div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Feb 29,=
 2024 at 4:45=E2=80=AFAM Armin Rigo &lt;<a href=3D"mailto:armin.rigo@gmail.=
com">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">Hi Logan,<br>
<br>
On Thu, 29 Feb 2024 at 08:37, Logan Chien &lt;<a href=3D"mailto:tzuhsiang.c=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:<=
br>
&gt; IIUC, the difference is that guard_not_invalidated is at a different l=
ocation.<br>
&gt;<br>
&gt; But I don&#39;t understand why the backend can affect the logs in the =
&#39;jit-log-opt-&#39; tag.<br>
<br>
There are a few ways to influence the front-end: for example, the<br>
&quot;support_*&quot; class-level flags.=C2=A0 Maybe the front-end did eith=
er do or<br>
skip a specific optimization when compared with x86, and it results<br>
only in a &#39;guard_not_invalidated&#39; being present or not (and then on=
ce<br>
it is emitted, it&#39;s not emitted again a few instructions below).=C2=A0 =
Or<br>
there are some other reasons.=C2=A0 But as a general rule, we can mostly<br=
>
ignore the position of &#39;guard_not_invalidated&#39;.=C2=A0 It should hav=
e no<br>
effect except in corner cases.<br>
<br>
&gt; Also, I found that reduce_logical_and (failed) and reduce_logical_xor =
(passed) are very different.<br>
&gt;<br>
&gt; Is there more information on the details of this test?=C2=A0 Any ideas=
 to debug this test case are very welcomed!=C2=A0 Thanks.<br>
<br>
A possibility is that some of these tests are flaky in the sense of<br>
passing half by chance on x86---I vaguely remember having some<br>
troubles sometimes.=C2=A0 It&#39;s sometimes hard to write tests without<br=
>
testing too many details.=C2=A0 Others may have better comments about them.=
<br>
Generally, it&#39;s OK to look at what you got and compare it with what<br>
the test expects.=C2=A0 If you can come up with a reason for why what you<b=
r>
got is correct too, and free of real performance issues, then that&#39;s<br=
>
good enough.<br>
<br>
A bient=C3=B4t,<br>
Armin<br>
</blockquote></div>

--0000000000008c84b906129eb81d--

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

--===============8967805982664191151==--