From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7KM3-0003uB-Pt for qemu-devel@nongnu.org; Sat, 03 Jan 2015 03:46:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y7KLy-0002yG-QY for qemu-devel@nongnu.org; Sat, 03 Jan 2015 03:46:39 -0500 Received: from mail-wi0-x234.google.com ([2a00:1450:400c:c05::234]:35359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y7KLy-0002yC-KX for qemu-devel@nongnu.org; Sat, 03 Jan 2015 03:46:34 -0500 Received: by mail-wi0-f180.google.com with SMTP id n3so592639wiv.13 for ; Sat, 03 Jan 2015 00:46:34 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54A7AC67.7070505@redhat.com> Date: Sat, 03 Jan 2015 09:46:31 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1415723092-4088-1-git-send-email-rth@twiddle.net> In-Reply-To: <1415723092-4088-1-git-send-email-rth@twiddle.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2.3 0/8] Linked list for tcg ops List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , Aurelien Jarno , qemu-devel On 11/11/2014 17:24, Richard Henderson wrote: > Currently tcg ops are simply placed in a buffer in order. Which is > fine until we want to actually do something with the opcode stream, > such as optimize them. Note the horrible things like call opcodes > needing their argument count both prefixed and postfixed so that we > can iterate across the call either forward or backward. > > While I'm changing this, I also move quite a lot of tcg-op.h out of > line. There is very little benefit to having most of them be inline, > since their arguments are extracted from the guest instructions being > translated, and thus their values are not really predictable. > > I chose a cutoff of one function call. If a tcg-op.h functionconsists > of a single function call, inline it, otherwise move it out of line. > > This also removes a bit of boilerplate from each target. > > I haven't been able to measure a performance difference with this > patch set. I wouldn't really expect any, as the complexity level > remains the same. I simply find the link list significantly more > maintainable. > > Of course this isn't intended for the upcoming 2.2 release. > > Comments? Happy new year! :) Are you going to submit this now? Paolo