From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51550) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSxIk-00009B-3C for qemu-devel@nongnu.org; Thu, 28 Jul 2016 22:13:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSxIf-0008If-TA for qemu-devel@nongnu.org; Thu, 28 Jul 2016 22:13:25 -0400 Message-ID: <1469758381.5978.241.camel@kernel.crashing.org> From: Benjamin Herrenschmidt Date: Fri, 29 Jul 2016 12:13:01 +1000 In-Reply-To: <76968d9e-1b45-538e-a400-9069eb72f42e@twiddle.net> References: <1469571686-7284-1-git-send-email-benh@kernel.crashing.org> <1469571686-7284-28-git-send-email-benh@kernel.crashing.org> <76968d9e-1b45-538e-a400-9069eb72f42e@twiddle.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 28/32] ppc: Avoid double translation for lvx/lvxl/stvx/stvxl List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org, david@gibson.dropbear.id.au On Fri, 2016-07-29 at 06:19 +0530, Richard Henderson wrote: > This, I'm not so keen on. >=20 > (1) The helper, since it writes to registers controlled by tcg, must be= =C2=A0 > described to clobber all registers.=C2=A0 Which will noticeably increas= e memory=C2=A0 > traffic to ENV.=C2=A0 For instance, you won't be able to hold the guest= register=C2=A0 > holding the address in a host register across the call. Ah I wasn't aware of this. How do you describe such a clobber ? Can I des= cribe specifically which one is clobbered ? I didn't think TCG kept track of th= e vector halves but I must admit I'm still a bit new with TCG in general. I noticed other constructs doing that (passing a register number to an op= code), what do I do to ensure the right clobbers are there ? > > (2) We're going to have to teach tcg about 16-byte data types soon an= yway, for=C2=A0 > the proper emulation of 16-byte atomic operations. Is anybody working on this already ? I thought about that approach as it would definitely make things easier for that and a couple of other cases such as lq/stq. Cheers, Ben.