From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Richard Henderson <richard.henderson@linaro.org>,
qemu-devel@nongnu.org,
"Catherine A. Frederick" <agrecascino123@gmail.com>
Subject: Re: [RFC] Various questions about TCG implementation, DRM patches dealing with pointers over guest-host barrier.
Date: Mon, 18 May 2020 11:52:15 +0100 [thread overview]
Message-ID: <877dx9ldls.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA-yTm7h_EGZ4_iKVGJ0GMFinWOyQXyKsYgs8s933Bnn1Q@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Mon, 18 May 2020 at 00:23, Catherine A. Frederick
> <agrecascino123@gmail.com> wrote:
>> Hi, I've been patching TCG for my own purposes recently and I was
>> wondering a few things. That being:
>>
<snip>
>> - I've been implementing an instruction scheduler(list scheduler, with
>> priority given to most successors) for TCG and currently if I replace
>> instructions in s->ops(the TCG context) I get a crash later in
>> tcg_reg_alloc_op, even if the instruction stream is identical. Is there
>> anything else I need to move when I do this?
>
> This one's out of my field of knowledge; Richard might know.
I'm a little unclear in what is happening here. For TCG plugins we
insert dummy ops into the stream so they can be replaced or removed at a
later phase in the translation.
>> - Is insn_start necessary to have in order(and what does it do?)? These
>> currently are serializing instructions in my scheduler and significantly
>> limit my reordering as they create lots of dependencies every few
>> instructions.
>
> The primary purpose of insn_start is to save information about the
> current instruction in a metadata
<snip>
> Finally, I haven't checked, but I suspect the new TCG plugin APIs
> implicitly assume that code for each insn is generated serially,
> ie that a plugin can do "for each instruction" type work on a
> callback that hangs off the insn_start op.
Spoiler alert: Yes it does ;-)
--
Alex Bennée
next prev parent reply other threads:[~2020-05-18 10:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-17 23:05 [RFC] Various questions about TCG implementation, DRM patches dealing with pointers over guest-host barrier Catherine A. Frederick
2020-05-18 10:21 ` Peter Maydell
2020-05-18 10:52 ` Alex Bennée [this message]
2020-05-19 14:51 ` 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=877dx9ldls.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=agrecascino123@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.