All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: lrwei <lrwei@bupt.edu.cn>
Cc: Richard Henderson <richard.henderson@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	qemu-discuss@nongnu.org
Subject: Re: Question on implementation detail of `temp_sync`
Date: Wed, 05 Aug 2020 09:39:28 +0100	[thread overview]
Message-ID: <874kphmqpr.fsf@linaro.org> (raw)
In-Reply-To: <tencent_3C5D583315945B14647C946B@qq.com>


lrwei <lrwei@bupt.edu.cn> writes:

> Sorry for the unintentional sending of an uncompleted message.

Questions about the internals of the TCG are very much in the remit of
qemu-devel so are likely to get missed on qemu-discuss which is more
aimed at user questions.

>
<re-pasted to fix html noise>

> I understands that the current code works, but gets confused on why `ts` needs to be loaded in to a register when `free_or_dead` is not
> set.

It isn't, the break leaves the switch statement once it stores the
constant to memory.

> For example in the following scenario:
> movi_i32    r0, 0x1
> add_i32      r1, r1, r0
> ...
> (where r0 is not used any more, and both r0 and r1 are globals)

> If I am not mistaken, the code gen procedure of the first IR will call `temp_sync` with `free_or_dead` not set, which load the constant in to
> a register and store it back to memory. At this time, `r0` will be `TEMP_VAL_REG` instead of `TEMP_VAL_CONST`, so the following IR can't
> embed this constant operand in the assembly instruction it produces. Also, this results in a seemingly useless register allocation (, why
> don't the further use of r0 use the constant directly?)

Is this what you are actually seeing generated? If you run with -d
in_asm,op,op_opt,out_asm it should be clear what actually happened.

> So I wonder whether there is any reason for this loading a constant into register, I'll be very appreciated if someone can point out the
> reason for me.

<snip>
>
>
> Thanks in advance.
> lrwei&nbsp; 
> &nbsp;
> ------------------&nbsp;Original&nbsp;------------------
> From: &nbsp;"lrwei"<lrwei@bupt.edu.cn&gt;;
> Date: &nbsp;Tue, Aug 4, 2020 12:06 PM
> To: &nbsp;"qemu-discuss"<qemu-discuss@nongnu.org&gt;; 
> Subject: &nbsp;Question on implementation detail of `temp_sync`
>
<re-pasted fixing html noise>

> Hello to the list,
> Recently I have been studying the code of TCG, and get confused by the following detail in function `temp_sync` in tcg/tcg.c:

>     case TEMP_VAL_CONST:
>         /* If we're going to free the temp immediately, then we won't
>            require it later in a register, so attempt to store the
>            constant to memory directly.  */
>         if (free_or_dead
>            && tcg_out_sti(s, ts->type, ts->val,
>                            ts->mem_base->reg, ts->mem_offset)) {
>            break;
>         }
>         temp_load(s, ts, tcg_target_available_regs[ts->type],
>                   allocated_regs, preferred_regs);
>         /* fallthrough */

> movi_i32

> Would it be better to remove the `free_or_dead` in the if statement, i.e. turn the function to be:

>     case TEMP_VAL_CONST:
>         if (tcg_out_sti(s, ts->type, ts->val,
>                            ts->mem_base->reg, ts->mem_offset)) {
>            break;
>         }
>         temp_load(s, ts, tcg_target_available_regs[ts->type],
>                   allocated_regs, preferred_regs);
>         /* fallthrough */


-- 
Alex Bennée


       reply	other threads:[~2020-08-05  8:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <tencent_61ECB8BB3639D7BF2284FBDC@qq.com>
     [not found] ` <tencent_3C5D583315945B14647C946B@qq.com>
2020-08-05  8:39   ` Alex Bennée [this message]
2020-08-06 15:53 Question on implementation detail of `temp_sync` lrwei

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=874kphmqpr.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=lrwei@bupt.edu.cn \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-discuss@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.