From: Richard Henderson <rth@twiddle.net>
To: Taylor Simpson <tsimpson@quicinc.com>,
Richard Henderson <richard.henderson@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH] Add support for a helper with 7 arguments
Date: Fri, 7 Feb 2020 15:49:44 +0000 [thread overview]
Message-ID: <a01b3358-a598-9d01-f3c8-d9a84fb7dd28@twiddle.net> (raw)
In-Reply-To: <BYAPR02MB4886E14CC87B1169B2F6BE2BDE1C0@BYAPR02MB4886.namprd02.prod.outlook.com>
On 2/7/20 12:43 PM, Taylor Simpson wrote:
>
>> -----Original Message-----
>> From: Richard Henderson <richard.henderson@linaro.org>
>>
>> But I encourage you to re-think your purely mechanical approach to the
>> hexagon port. It seems to me that you should be doing much more during
>> the translation phase so that you can minimize the number of helpers that
>> you require.
>
> There are a couple of things we could do
> - Short term: Add #ifdef's to the generated code so that the helper isn't
> compiled when there is a fWRAP_<tag> defined. There are currently ~500
> instructions where this is the case.
Definitely.
> - Long term: Integrate rev.ng's approach that uses flex/bison to parse the
> semantics and generate TCG code.
There is perhaps an intermediate step that merely special-cases the load/store
insns. With rare exceptions (hah!) these are the cases that will most often
raise an exception. Moreover, they are the *only* cases that can raise an
exception without requiring a helper call anyway.
There are a number of cases that I can think of:
{
r6 = memb(r1)
r7 = memb(r2)
}
qemu_ld t0, r1, MO_UB, mmu_idx
qemu_ld t1, r2, MO_UB, mmu_idx
mov r6, t0
mov r7, t1
{
r6 = memb(r1)
memb(r2) = r7
}
qemu_ld t0, r1, MO_UB, mmu_idx
qemu_st r7, r2, MO_UB, mmu_idx
mov r6, t0
These being the "normal" case wherein the memops are unconditional, and can
simply use a temp for semantics. Similarly for MEMOP, NV, or SYSTEM insns in
slot0.
{
r6 = memb(r1)
if (p0) r7 = memb(r7)
}
qemu_ld l0, r1, MO_UB, mmu_idx
andi t1, p0, 1
brcondi t1, 0, L1
qemu_ld r7, r2, MO_UB, mmu_idx
L1:
mov r6, l0
For a conditional load in slot 0, we can load directly into the final
destination register and skip the temporary.
Because TCG doesn't do global register allocation, any temporary crossing a
basic block boundary gets flushed to stack. So this avoids sending the r7
value through an unnecessary round trip.
This works because (obviously) nothing can raise an exception after slot0, and
the only thing that comes after is the commit phase. This can be extended to a
conditional load in slot1, when we notice that the insn in slot0 cannot raise
an exception.
{
memb(r1) = r3
memb(r2) = r4
}
call helper_probe_access, r1, MMU_DATA_STORE, 1
call helper_probe_access, r2, MMU_DATA_STORE, 1
qemu_st r3, r1, MO_UB, mmu_idx
qemu_st r4, r2, MO_UB, mmu_idx
{
memb(r1) = r3
r4 = memb(r2)
}
call helper_probe_access, r1, MMU_DATA_STORE, 1
call helper_probe_access, r2, MMU_DATA_LOAD, 1
qemu_st r3, r1, MO_UB, mmu_idx
qemu_ld r4, r2, MO_UB, mmu_idx
These cases with a store in slot1 are irritating, because I see that (1) all
exceptions must be recognized before anything commits, and (2) slot1 exceptions
must have preference over slot0 exceptions. But we can probe them easily enough.
> - Long long term: A much more general approach will be to turn the C
> semantics code into LLVM IR and generate TCG from the IR.
Why would you imagine this to be more interesting than using flex/bison?
r~
next prev parent reply other threads:[~2020-02-07 15:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-05 22:41 [PATCH] Add support for a helper with 7 arguments Taylor Simpson
2020-02-06 6:02 ` Richard Henderson
2020-02-06 10:28 ` Richard Henderson
2020-02-06 14:03 ` Taylor Simpson
2020-02-06 15:35 ` Richard Henderson
2020-02-06 17:52 ` Taylor Simpson
2020-02-07 0:27 ` Richard Henderson
2020-02-07 4:46 ` Taylor Simpson
2020-02-07 8:53 ` Richard Henderson
2020-02-07 11:59 ` Taylor Simpson
2020-02-07 12:14 ` Richard Henderson
2020-02-07 12:43 ` Taylor Simpson
2020-02-07 15:49 ` Richard Henderson [this message]
2020-02-09 5:08 ` Taylor Simpson
2020-02-09 18:17 ` Richard Henderson
2020-02-09 20:51 ` Taylor Simpson
2020-02-10 4:54 ` Taylor Simpson
2020-02-10 16:33 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a01b3358-a598-9d01-f3c8-d9a84fb7dd28@twiddle.net \
--to=rth@twiddle.net \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=tsimpson@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).