From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULFal-0008Ta-4s for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:22:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULFae-0003sU-6U for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:22:19 -0400 Received: from mail-oa0-f43.google.com ([209.85.219.43]:48029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULFae-0003sG-1X for qemu-devel@nongnu.org; Thu, 28 Mar 2013 12:22:12 -0400 Received: by mail-oa0-f43.google.com with SMTP id l10so10163903oag.30 for ; Thu, 28 Mar 2013 09:22:11 -0700 (PDT) Sender: Richard Henderson Message-ID: <51546E2E.9020408@twiddle.net> Date: Thu, 28 Mar 2013 09:22:06 -0700 From: Richard Henderson MIME-Version: 1.0 References: <1364484781-15561-1-git-send-email-rth@twiddle.net> <1364484781-15561-9-git-send-email-rth@twiddle.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 08/20] tcg-arm: Implement deposit for armv7 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, Aurelien Jarno On 03/28/2013 09:15 AM, Peter Maydell wrote: >> + /* ??? Without bfi, we could improve over generic code by combining >> + the right-shift from a non-zero ofs with the orr. We do run into >> + problems when rd == rs, and the mask generated from ofs+len don't >> + fit into an immediate. We would have to be careful not to pessimize >> + wrt the optimizations performed on the expanded code. */ >> + return use_armv7_instructions; > > Strictly speaking BFI is v6T2, but there doesn't seem much point > in making the distinction given it would only affect the rare > ARM1156. (Personally I don't think there's much point worrying about > optmising codegen for anything pre-v7 at all.) Fair enough. I could update the comment to include v6t2, since I've done similar for e.g. v6k (while retaining the v7 test) elsewhere in the patch set. > What guarantees us that we won't see a length of 0? > The tcg/README description doesn't say that's invalid > and I don't think the optimize pass handles it (maybe I > missed it). We can patch the readme, and the asserts in tcg-op.h if you like. I've assumed elsewhere that we won't see a zero length. E.g. none of the other cpus -- ppc, hppa, ia64 -- can encode that either. r~