qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Blue Swirl <blauwirbel@gmail.com>
To: Filip Navara <filip.navara@gmail.com>
Cc: Laurent Desnogues <laurent.desnogues@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/3] RFC: TCG ARM optimizations
Date: Mon, 29 Jun 2009 21:58:56 +0300	[thread overview]
Message-ID: <f43fc5580906291158g315368e4s288db6e2e374aef7@mail.gmail.com> (raw)
In-Reply-To: <5b31733c0906291126l5c4df229pdfd9e7faf88aa292@mail.gmail.com>

On 6/29/09, Filip Navara <filip.navara@gmail.com> wrote:
>  Lastly, the code generated for softmmu memory loads/stores could
>  probably be optimized in some cases. It uses hard-coded registers.
>  It's not optimized for multiple stores to adjacent locations (pushing
>  multiple registers to stack) and does all the calculations again and
>  again. This results not only in recomputing numbers we already have
>  (as long as the stack is still on the same guest page), but also in
>  huge TBs. I imagine that doesn't help the processor cache too much.
>  This would probably benefit all targets. In fact I believe the softmmu
>  code could be moved out of the TCG target-specific code and into the
>  main code (with the possibility to override it with optimized
>  version).

Interesting. We could add a new optional TCG instruction op_ld_g2h
(extracted from qemu_ld) that performs the TLB lookup and returns the
host address. When multiple accesses near the same guest address are
detected (how?), the translator can reuse the host address, perform
some math and check if the guest page is still same. If true, ld_raw
can be used, otherwise recalculate the host address.

On the performance side, qemu_ld on Sparc host uses 9 instructions in
the TLB hit case before the access. Maybe this would lower the number
a bit but not too much.

      reply	other threads:[~2009-06-29 18:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-29 17:50 [Qemu-devel] [PATCH 0/3] RFC: TCG ARM optimizations Filip Navara
2009-06-29 17:59 ` Laurent Desnogues
2009-06-29 18:26   ` Filip Navara
2009-06-29 18:58     ` Blue Swirl [this message]

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=f43fc5580906291158g315368e4s288db6e2e374aef7@mail.gmail.com \
    --to=blauwirbel@gmail.com \
    --cc=filip.navara@gmail.com \
    --cc=laurent.desnogues@gmail.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 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).