From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo0dd-0003EO-GQ for qemu-devel@nongnu.org; Tue, 03 Dec 2013 19:48:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vo0dV-0002iM-1k for qemu-devel@nongnu.org; Tue, 03 Dec 2013 19:48:25 -0500 Received: from mail-yh0-x22e.google.com ([2607:f8b0:4002:c01::22e]:60718) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vo0dU-0002hg-Sk for qemu-devel@nongnu.org; Tue, 03 Dec 2013 19:48:16 -0500 Received: by mail-yh0-f46.google.com with SMTP id l109so10900199yhq.33 for ; Tue, 03 Dec 2013 16:48:16 -0800 (PST) Sender: Richard Henderson Message-ID: <529E7BC8.6070100@twiddle.net> Date: Wed, 04 Dec 2013 13:48:08 +1300 From: Richard Henderson MIME-Version: 1.0 References: <1386107477-24165-1-git-send-email-peter.maydell@linaro.org> <1386107477-24165-13-git-send-email-peter.maydell@linaro.org> <529E7310.6070303@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 12/12] target-arm: A64: add support for compare and branch imm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Patch Tracking , Michael Matz , QEMU Developers , Alexander Graf , C Fontana , Dirk Mueller , Laurent Desnogues , "kvmarm@lists.cs.columbia.edu" On 12/04/2013 01:32 PM, Peter Maydell wrote: > You're right that we can just make this function return the TCGv > temp rather than making the caller pass one in. Are you suggesting > the 64-bit case should return cpu_X[reg] rather than a copy of it, > though? I think it would be pretty hard to reason about if you had to > remember that sometimes you got a trashable copy and sometimes > the real register. I think that the normal case is to write to the output in one step, and thus having an input overlap an output isn't your problem but tcg's. I would think the case of multi-step output to be fairly rare, and easily solvable by always allocating an output temporary. Am I off-base on the multi-output thing? Modulo flags setting, of course, but I think that special case ought to be relatively solvable. > (I'm still a bit on the fence about that pool of auto-freeing temporaries. > Manual temp management is certainly a fertile source of decoder bugs, > but in the longer term we might want to push the functionality down into > the common code rather than having an ad-hoc thing in one decoder.) See also Sparc and S390. ;-) I'm open to suggestions for doing this generically, but I've no great ideas off-hand. r~