All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.