From: "Alex Bennée" <alex.bennee@linaro.org>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org, aurelien@aurel32.net
Subject: Re: [Qemu-devel] [PATCH 06/16] tcg: Add temp_global bit to TCGTemp
Date: Wed, 28 Jun 2017 09:52:04 +0100 [thread overview]
Message-ID: <87mv8swl3f.fsf@linaro.org> (raw)
In-Reply-To: <5554273c-7858-9048-5c2c-4677884baff5@twiddle.net>
Richard Henderson <rth@twiddle.net> writes:
> On 06/27/2017 01:39 AM, Alex Bennée wrote:
>>> + /* If true, the temp is saved across both basic blocks and
>>> + translation blocks. */
>>> + unsigned int temp_global:1;
>>> + /* If true, the temp is saved across basic blocks but dead
>>> + at the end of translation blocks. If false, the temp is
>>> + dead at the end of basic blocks. */
>>> + unsigned int temp_local:1;
>>> + unsigned int temp_allocated:1;
>>
>> This is where my knowledge of the TCG internals gets slightly confused.
>> As far as I'm aware all our TranslationBlocks are Basic Blocks - they
>> don't have any branches until the end of the block. What is the
>> distinction here?
>>
>> Is a temp_global truly global? I thought the guest state was fully
>> rectified by the time we leave the basic block.
>
> TranslationBlocks are not basic blocks. They normally stop at
> branches in the target instruction stream, but they certainly may have
> many branches in the tcg opcode stream (brcond and the like).
> Consider, for instance, our implementation of arm32's conditional
> instructions.
Right. Re-reading the tcg/README it does make the distinction but the
term "basic block" is overloaded depending on when talking about the
guest instructions or the generated code.
>
> Beyond that, I agree the language is confusing.
>
> A temp_global is created by tcg_global_mem_new_*, generally represents
> a cpu register, and is synced back to a slot in ENV.
>
> A temp_local is created by tcg_temp_local_new_*, and is synced to a
> slot in the local stack frame.
The language from the README:
A TCG "temporary" is a variable only live in a basic
block. Temporaries are allocated explicitly in each function.
A TCG "local temporary" is a variable only live in a function. Local
temporaries are allocated explicitly in each function.
I must admit I hadn't quite understood the distinction. In the ARM code
the only place where tcg_temp_local_new() over tcg_temp_new() is used is
in the ld/strex code. I guess because you need to preserve its value
over a potential TCG branch?
I guess in translate-a64/gen_store_exclusive() the key lines are:
TCGv_i64 addr = tcg_temp_local_new_i64();
/* Copy input into a local temp so it is not trashed when the
* basic block ends at the branch insn.
*/
tcg_gen_mov_i64(addr, inaddr);
tcg_gen_brcond_i64(TCG_COND_NE, addr, cpu_exclusive_addr, fail_label);
> Something without either is simply declared dead at the end of a basic
> block, and is a source of confusion to those writing new front-ends.
I'll see if I can come up with some improved wording to help new
developers in the future.
> Anyway, we already have all of these concepts. The change is that
> before the patch the only way to tell a temp_global is to compare the
> index against tcg_ctx.nb_global.
Indeed. As I have previously really only been a consumer of the TCG API
I'm taking the opportunity to learn more about the internals as the
vector work is likely to touch it ;-)
>
>
> r~
--
Alex Bennée
next prev parent reply other threads:[~2017-06-28 8:51 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-21 2:48 [Qemu-devel] [PATCH 00/16] Cleanups within TCG middle-end Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 01/16] tcg: Merge opcode arguments into TCGOp Richard Henderson
2017-06-26 14:44 ` Alex Bennée
2017-06-26 14:55 ` Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 02/16] tcg: Propagate args to op->args in optimizer Richard Henderson
2017-06-26 14:53 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 03/16] tcg: Propagate args to op->args in tcg.c Richard Henderson
2017-06-26 15:02 ` Alex Bennée
2017-06-26 15:07 ` Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 04/16] tcg: Propagate TCGOp down to allocators Richard Henderson
2017-06-26 15:08 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 05/16] tcg: Introduce arg_temp Richard Henderson
2017-06-26 16:37 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 06/16] tcg: Add temp_global bit to TCGTemp Richard Henderson
2017-06-27 8:39 ` Alex Bennée
2017-06-27 16:17 ` Richard Henderson
2017-06-28 8:52 ` Alex Bennée [this message]
2017-06-21 2:48 ` [Qemu-devel] [PATCH 07/16] tcg: Return NULL temp for TCG_CALL_DUMMY_ARG Richard Henderson
2017-06-27 8:47 ` Alex Bennée
2017-06-27 16:36 ` Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 08/16] tcg: Introduce temp_arg Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 09/16] tcg: Use per-temp state data in liveness Richard Henderson
2017-06-27 8:57 ` Alex Bennée
2017-06-27 16:39 ` Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 10/16] tcg: Avoid loops against variable bounds Richard Henderson
2017-06-27 9:01 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 11/16] tcg: Change temp_allocate_frame arg to TCGTemp Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 12/16] tcg: Remove unused TCG_CALL_DUMMY_TCGV Richard Henderson
2017-06-27 9:42 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 13/16] tcg: Export temp_idx Richard Henderson
2017-06-27 9:46 ` Alex Bennée
2017-06-27 16:43 ` Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 14/16] tcg: Use per-temp state data in optimize Richard Henderson
2017-06-27 9:59 ` Alex Bennée
2017-06-21 2:48 ` [Qemu-devel] [PATCH 15/16] tcg: Define separate structures for TCGv_* Richard Henderson
2017-06-21 2:48 ` [Qemu-devel] [PATCH 16/16] tcg: Store pointers to temporaries directly in TCGArg Richard Henderson
2017-06-21 3:43 ` [Qemu-devel] [PATCH 00/16] Cleanups within TCG middle-end no-reply
2017-06-26 16:49 ` Alex Bennée
2017-06-26 17:47 ` Richard Henderson
2017-06-26 19:19 ` Alex Bennée
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=87mv8swl3f.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=aurelien@aurel32.net \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).