From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbhD-0003SH-3v for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:42:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHbh4-00044n-NF for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:42:11 -0400 Received: from mail-qe0-x235.google.com ([2607:f8b0:400d:c02::235]:63001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHbh4-00044f-JI for qemu-devel@nongnu.org; Thu, 05 Sep 2013 11:42:02 -0400 Received: by mail-qe0-f53.google.com with SMTP id 1so876401qee.40 for ; Thu, 05 Sep 2013 08:42:02 -0700 (PDT) Sender: Richard Henderson Message-ID: <5228A646.4000006@twiddle.net> Date: Thu, 05 Sep 2013 08:41:58 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1378144503-15808-1-git-send-email-rth@twiddle.net> <1378144503-15808-20-git-send-email-rth@twiddle.net> <522887E0.409@huawei.com> In-Reply-To: <522887E0.409@huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 19/29] tcg-aarch64: Introduce tcg_fmt_Rd_uimm_s List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Claudio Fontana Cc: qemu-devel@nongnu.org On 09/05/2013 06:32 AM, Claudio Fontana wrote: >> { >> - uint32_t half, base, shift, movk = 0; >> - /* construct halfwords of the immediate with MOVZ/MOVK with LSL */ >> - /* using MOVZ 0x52800000 | extended reg.. */ >> - base = (value > 0xffffffff) ? 0xd2800000 : 0x52800000; >> - /* count trailing zeros in 16 bit steps, mapping 64 to 0. Emit the >> - first MOVZ with the half-word immediate skipping the zeros, with a shift >> - (LSL) equal to this number. Then morph all next instructions into MOVKs. >> - Zero the processed half-word in the value, continue until empty. >> - We build the final result 16bits at a time with up to 4 instructions, >> - but do not emit instructions for 16bit zero holes. */ > > Please do not remove these comments. > In my judgement this part of the code profits from some verbose clarification. > What is happening might be obvious to you, but not to others trying to step in. Fair enough. > In general I'd prefer to keep movi as it was (functionally-wise) for the > time being, replacing it with a more efficient version once we can get some > numbers (which will be soon) with which to justify (or not) the added code > complexity. The most important thing we're not doing at the moment is handling negative numbers efficiently. E.g. we're using 4 insns to load -1. r~