All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aurelien Jarno <aurelien@aurel32.net>
To: Paul Brook <paul@codesourcery.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC][PATCH] tcg: allocate memory to spill registers on startup
Date: Fri, 10 Apr 2009 17:31:26 +0200	[thread overview]
Message-ID: <49DF664E.2080607@aurel32.net> (raw)
In-Reply-To: <200904101620.10589.paul@codesourcery.com>

Paul Brook a écrit :
> On Friday 10 April 2009, Aurelien Jarno wrote:
>> On Fri, Apr 10, 2009 at 03:44:55PM +0100, Paul Brook wrote:
>>> On Friday 10 April 2009, Aurelien Jarno wrote:
>>>> +    assert(size != TCG_MAX_TEMPS * sizeof(tcg_target_long));
>>> Shouldn't this be >= ?
>> When I wrote that, I thought that the two sizes have to match, 
> 
> In that case I think the assert is completely wrong. You're asserting that the 
> two values are not equal. IIRC there's bits in the TCG headers that disable 
> asserts by default - I've been bitten by this before.

Correct.

>> but you are right, the frame size can actually be bigger.
>> Any other comment?
> 
> What were you benchmarking? Translation speed or execution speed?
> I'd guess that your new code speeds up the translator, but makes the resulting 
> code less cache friendly.

Execution speed, that is compilation of a small software in
qemu-system-mips64. I haven't try to do find which parts of QEMU goes
faster, but I agree with your hypothesis.

> Maybe if I see your subsequent optimization it might make more sense, though 
> I'm suspicious of tcg-target doing register allocation/spilling itself.

I am trying to fix the following comment from Fabrice (tcg.c)

/* XXX: for load/store we could do that only for the slow path
   (i.e. when a memory callback is called) */

The idea is not to do register allocation/spilling in tcg-target.c, but
to save registers containing TCG globals to memory in the slow path only
and without touching the TCGTemp structure. That's why it has to be done
in tcg-target.c

I currenty only have an hackish patch that does not fully work. I guess
the best is to resent the current patch along with the slow path
optimization one when it works.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

  reply	other threads:[~2009-04-10 15:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-10  8:54 [Qemu-devel] [RFC][PATCH] tcg: allocate memory to spill registers on startup Aurelien Jarno
2009-04-10 14:44 ` Paul Brook
2009-04-10 14:56   ` Aurelien Jarno
2009-04-10 15:20     ` Paul Brook
2009-04-10 15:31       ` Aurelien Jarno [this message]
2009-04-10 15:52         ` Paul Brook
2009-04-10 16:06           ` Aurelien Jarno

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=49DF664E.2080607@aurel32.net \
    --to=aurelien@aurel32.net \
    --cc=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.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.