From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHs0b-0006h5-3D for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:07:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHs0V-0005Z1-4D for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:07:17 -0400 Received: from lhrrgout.huawei.com ([194.213.3.17]:2557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHs0U-0005Xj-PE for qemu-devel@nongnu.org; Fri, 06 Sep 2013 05:07:11 -0400 Message-ID: <52299B2C.9030400@huawei.com> Date: Fri, 6 Sep 2013 11:06:52 +0200 From: Claudio Fontana 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> <5228A646.4000006@twiddle.net> In-Reply-To: <5228A646.4000006@twiddle.net> 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: Richard Henderson Cc: qemu-devel@nongnu.org On 05.09.2013 17:41, Richard Henderson wrote: > 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. Ok, lets punctually address that then. > r~ > Claudio