qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Various questions about TCG implementation, DRM patches dealin


From: Alex Bennée
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
User-agent: mu4e 1.4.6; emacs 28.0.50

Peter Maydell <address@hidden> writes:

> On Mon, 18 May 2020 at 00:23, Catherine A. Frederick
> <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]