From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60363) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZe3-0003Vz-QD for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:00:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLZdz-000088-Kg for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:00:39 -0500 Received: from mail-oi0-x244.google.com ([2607:f8b0:4003:c06::244]:33897) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLZdz-00007v-EO for qemu-devel@nongnu.org; Tue, 19 Jan 2016 12:00:35 -0500 Received: by mail-oi0-x244.google.com with SMTP id x140so14379649oif.1 for ; Tue, 19 Jan 2016 09:00:35 -0800 (PST) Date: Tue, 19 Jan 2016 18:00:29 +0100 From: "Edgar E. Iglesias" Message-ID: <20160119170029.GS29396@toto> References: <145287209895.25408.12995870835200275306.stgit@localhost> <145287210479.25408.17499099590726683703.stgit@localhost> <56993854.1030802@twiddle.net> <87egdi1u1y.fsf@fimbulvetr.bsc.es> <569955F4.4000607@twiddle.net> <87pox1xmwv.fsf@fimbulvetr.bsc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87pox1xmwv.fsf@fimbulvetr.bsc.es> Subject: Re: [Qemu-devel] [PATCH v1 1/2] tcg: Add support for constant value promises List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?iso-8859-1?Q?Llu=EDs?= Vilanova Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org, Richard Henderson On Sat, Jan 16, 2016 at 09:57:36PM +0100, Lluís Vilanova wrote: > Richard Henderson writes: > > > On 01/15/2016 12:12 PM, Lluís Vilanova wrote: > >> Richard Henderson writes: > >> > >>> On 01/15/2016 07:35 AM, Lluís Vilanova wrote: > >>>> +TCGv_i64 tcg_promise_i64(TCGv_promise_i64 *promise) > >>>> +{ > >>>> + int pi = tcg_ctx.gen_next_parm_idx; > >>>> + *promise = (TCGv_promise_i64)&tcg_ctx.gen_opparam_buf[pi]; > >>>> + return tcg_const_i64(0xdeadcafe); > >>>> +} > >> > >>> This doesn't work for a 32-bit host. The constant may be split across two > >>> different parameter indices, and you don't know exactly where the second will be. > >> > >>> Because of that, I think this is over-engineered, and really prefer the simpler > >>> interface that Edgar posted last week. > >> > >> In this case, 'tcg_set_promise_i64' sets the two arguments accordingly on 32-bit > >> targets. Both solutions depend on TCG internals (in this specific case the > >> implementation of 'tcg_gen_movi_i64'), but now it's all implemented inside TCG. > >> > >> Alternatively, promises could use the longer route of recording the opcode index > >> (as Edgar did AFAIR), and retrieve the argument pointer from there. Still, for > >> 32-bit targets we have to assume the two immediate moves are gonna generate two > >> consecutive opcodes. > > > Your solution also doesn't help Edgar, since he's interested in modifying an > > argument to the insn_start opcode, not modifying a literal constant in a move. > > I wasn't aware of that. If the idea was to use this for more than immediates > stored in TCGv values, I see two options. First, modify the necessary opcodes to > use a TCGv argument instead of an immediate. Second, generalize this patch to > to select any opcode argument. > > An example of the generalization when used to reimplement icount: > > // insn count placeholder > TCGv_i32 imm = tcg_const_i32(0xcafecafe); > // insn count promise > TCGv_promise_i32 imm_promise = tcg_promise_i32( > 1, // how many opcodes to go "backwards" > 1); // what argument to modify on that opcode > // operate with imm > ... > // resolve value > tcg_set_promise_i32(imm_promise, insn_count); > > The question still stands on how to cleanly handle promises for opcodes like a > 64-bit mov on a 32-bit host (it's generated as two opcodes). Using this > interface would still be cleaner than directly manipulating the low-level TCG > arrays, and makes it easier to adopt it in future changes. > Thanks Lluis and Richard, I'll stay with my version for the first try at the ARM load/store fault reporting. If something better comes along that works for me, I'm happy to change. Richard if you want to take the patches through your tree feel free to do so. Otherwise, I'll post them again with more context and try through the ARM queue. Best regards, Edgar