From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59982) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLxeK-0007sa-Gp for qemu-devel@nongnu.org; Tue, 17 Sep 2013 11:57:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VLxeC-0001JC-0D for qemu-devel@nongnu.org; Tue, 17 Sep 2013 11:57:12 -0400 Received: from mail-ob0-x232.google.com ([2607:f8b0:4003:c01::232]:48524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VLxeB-0001Iu-QH for qemu-devel@nongnu.org; Tue, 17 Sep 2013 11:57:03 -0400 Received: by mail-ob0-f178.google.com with SMTP id uy5so5612630obc.37 for ; Tue, 17 Sep 2013 08:57:02 -0700 (PDT) Sender: Richard Henderson Message-ID: <52387BCA.4070407@twiddle.net> Date: Tue, 17 Sep 2013 08:56:58 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1379195690-6509-1-git-send-email-rth@twiddle.net> <1379195690-6509-23-git-send-email-rth@twiddle.net> <5236CC6D.40901@huawei.com> <523728D1.6060600@twiddle.net> <52380AE6.40007@huawei.com> In-Reply-To: <52380AE6.40007@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 22/33] tcg-aarch64: Use MOVN in tcg_out_movi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Claudio Fontana Cc: peter.maydell@linaro.org, qemu-devel@nongnu.org On 09/17/2013 12:55 AM, Claudio Fontana wrote: > On 16.09.2013 17:50, Richard Henderson wrote: >> On 09/16/2013 02:16 AM, Claudio Fontana wrote: >>> I agree in general with the approach "lets see if it is more convenient to start with MOVN". >>> The existing implementation is, although not easy, leaner. >>> Can we make it a little this one a little bit leaner? >> >> This sentence is not well formed. What did you mean? >> >> In what sense did you mean "lean"? Smaller or faster? >> If faster, see the comment about using neon insns. >> If smaller... um... why? > > I am not suggesting implementing the neon insns based thing. > I am suggesting looking at ways to reduce the size and complexity of the code needed to implement the same thing you just posted. > If you don't see the why, there is probably little I can say to change that. I interpreted you meaning akin to -Os, producing a smaller binary. I obviously wrote it in the least complex way I could think to do the job. If you can find a simpler way, feel free. r~