qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Richard Henderson <richard.henderson@linaro.org>
To: David Hildenbrand <david@redhat.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, alex.bennee@linaro.org, stefanha@redhat.com
Subject: Re: [RFC v2 2/5] cputlb: Replace switches in load/store_helper with callback
Date: Thu, 19 Sep 2019 08:10:21 -0700	[thread overview]
Message-ID: <662b0ca3-9ce4-53d9-723c-76aa242616ea@linaro.org> (raw)
In-Reply-To: <b11701c0-63cd-f313-fc0b-f66cb6d2f10a@redhat.com>

On 9/19/19 7:53 AM, David Hildenbrand wrote:
> On 18.09.19 20:02, Richard Henderson wrote:
>> Add a function parameter to perform the actual load/store to ram.
>> With optimization, this results in identical code.
>>
>> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
>> ---
>>  accel/tcg/cputlb.c | 159 +++++++++++++++++++++++----------------------
>>  1 file changed, 83 insertions(+), 76 deletions(-)
> 
> I would have guessed the compiler propagates the constant and eliminates
> the switch completely for the variants. After all, we now have more LOC ...
> 
> I would have moved the actual read/write to a separate function
> containing the switch statement instead.

I tried that.

The compiler does fold away the constant and eliminate the switch for the code
as-is.  But it somehow fails to do so for op ^ MO_BSWAP, where op is constant.
 I don't know why.

These little inline functions were the third try and the only one for which all
of the indirection folded away.  Not so much here, but in the next patch which
passes in the reverse-endian function as well.


>> +/* Wrap the unaligned load helpers to that they have a common signature.  */
>> +static inline uint64_t wrap_ldub(const void *haddr)
>> +{
>> +    return ldub_p(haddr);
> 
> I wonder if you should just add proper type cast to all of the <
> uint64_t accessors (e.g., here (uint8_t) ). Shouldn't hurt and makes
> people wonder less how the conversion from the int these accessors
> return to uint64_t will turn out.
> 
> But yeah, you're simply moving code here.

Perhaps.  I'm not really a fan of redundant casts.


r~


  reply	other threads:[~2019-09-19 15:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-18 18:02 [Qemu-devel] [RFC v2 0/5] Move notdirty handling to cputlb Richard Henderson
2019-09-18 18:02 ` [Qemu-devel] [RFC v2 1/5] cputlb: Disable __always_inline__ without optimization Richard Henderson
2019-09-19 14:36   ` David Hildenbrand
2019-09-18 18:02 ` [Qemu-devel] [RFC v2 2/5] cputlb: Replace switches in load/store_helper with callback Richard Henderson
2019-09-19 14:53   ` David Hildenbrand
2019-09-19 15:10     ` Richard Henderson [this message]
2019-09-18 18:02 ` [Qemu-devel] [RFC v2 3/5] cputlb: Introduce TLB_BSWAP Richard Henderson
2019-09-19 15:09   ` David Hildenbrand
2019-09-19 15:13     ` Richard Henderson
2019-09-18 18:02 ` [Qemu-devel] [RFC v2 4/5] exec: Adjust notdirty tracing Richard Henderson
2019-09-19 15:40   ` David Hildenbrand
2019-09-18 18:02 ` [Qemu-devel] [RFC v2 5/5] cputlb: Move NOTDIRTY handling from I/O path to TLB path Richard Henderson
2019-09-19 10:27 ` [Qemu-devel] [RFC v2 0/5] Move notdirty handling to cputlb no-reply
2019-09-19 12:19 ` no-reply
2019-09-19 12:22 ` no-reply
2019-09-21 22:21 ` 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=662b0ca3-9ce4-53d9-723c-76aa242616ea@linaro.org \
    --to=richard.henderson@linaro.org \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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).