From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31543 invoked by alias); 8 Jul 2014 19:09:23 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 31402 invoked by uid 89); 8 Jul 2014 19:09:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f178.google.com Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 08 Jul 2014 19:09:15 +0000 Received: by mail-ob0-f178.google.com with SMTP id wn1so6924290obc.23 for ; Tue, 08 Jul 2014 12:09:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nVSV58t35sB8nNYWuBPtUTysS53pKvIBJobZaHBkj/w=; b=krIlcrmEf+vzPN0qzEty3+v8hXQGFqXBzpYAkX+7A5/Lf15lIo8Dz1tMyPVgJ5KHrM zF5HcSPB3yEIts0ObvnouFpIMsMYOb3GeL93UINtVPqeND+bhU2vP+KH1jK24Bg/thv7 zio5YVk7pl02jSzajdCW+WROOt/jrPKSakdhBOb/pzeSiOw4uE1c/QJ/ATVB2R4BZad1 9q4sI8Z9+RENpnShOIBb1Zu6jf8V3UZRI4rW4mmc5Sv8MIhKDxhRgcVsrJ0EQUVFeVel ce5soIWKZGaumcds+dI5f8Qmghwdf/OlylfU+qdrDsJiW1C9s8BOBna+DnkLfBePU6V7 IzFQ== X-Gm-Message-State: ALoCoQmynaRu6Hf1X5hhqvVOFLcS5XaNQWVGHg7qIVzgoeqSKtFdNwBeZGMJOcB4XcJh/ENsMwGX X-Received: by 10.60.161.167 with SMTP id xt7mr8369168oeb.42.1404846553083; Tue, 08 Jul 2014 12:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.22.11 with HTTP; Tue, 8 Jul 2014 12:08:53 -0700 (PDT) In-Reply-To: <87lhs4f5ng.fsf@br87z6lw.de.ibm.com> References: <1403714949-28133-1-git-send-email-arnez@linux.vnet.ibm.com> <1403714949-28133-3-git-send-email-arnez@linux.vnet.ibm.com> <87lhs4f5ng.fsf@br87z6lw.de.ibm.com> From: Omair Javaid Date: Tue, 08 Jul 2014 19:09:00 -0000 Message-ID: Subject: Re: [PATCH v2 02/13] regcache: Add functions suitable for regset_supply/collect. To: Andreas Arnez Cc: "gdb-patches@sourceware.org" , Yao Qi , Mark Kettenis Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00155.txt.bz2 On 8 July 2014 16:31, Andreas Arnez wrote: > On Mon, Jul 07 2014, Omair Javaid wrote: > >> Is there a way around avoiding the loop in supply/collect where regnum >> != -1? It should be more efficient in cases where we are looking for a >> register with regnum > 0. > > Good question. The most straightforward way would be a register map > format where regnum is used as an index into an array of offsets, like > this: > > int s390_regmap_gregset[S390_NUM_REGS] = > { > /* Program Status Word. */ > 0x00, 0x04, > /* General Purpose Registers. */ > 0x08, 0x0c, 0x10, 0x14, > 0x18, 0x1c, 0x20, 0x24, > 0x28, 0x2c, 0x30, 0x34, > 0x38, 0x3c, 0x40, 0x44, > /* Access Registers. */ > 0x48, 0x4c, 0x50, 0x54, > 0x58, 0x5c, 0x60, 0x64, > 0x68, 0x6c, 0x70, 0x74, > 0x78, 0x7c, 0x80, 0x84, > /* Floating Point Control Word. */ > -1, > /* Floating Point Registers. */ > -1, -1, -1, -1, -1, -1, -1, -1, > -1, -1, -1, -1, -1, -1, -1, -1, > /* GPR Uppper Halves. */ > -1, -1, -1, -1, -1, -1, -1, -1, > -1, -1, -1, -1, -1, -1, -1, -1, > /* GNU/Linux-specific optional "registers". */ > 0x88, -1, -1, > }; > > This is a real example. For the full example refer to: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/s390-tdep.c;h=72d55450225e89da4394079efac1fa33b36cb68c;hb=d91fab15e7eb04f6c9b7fee5859d8815b7aa84ee#l412 > > As you see, this is where the s390 implementation came from. Then I > realized that regnum > 0 is a very rare case, and that the common case > was suboptimal with this format, because the supply/collect functions > had to iterate over *all* registers, not just those of a specific > regset. > > Patch #3 in this series expresses the regmap from above like this: > > static const struct regcache_map_entry s390_gregmap[] = > { > { 1, S390_PSWM_REGNUM }, > { 1, S390_PSWA_REGNUM }, > { 16, S390_R0_REGNUM }, > { 16, S390_A0_REGNUM }, > { 1, S390_ORIG_R2_REGNUM }, > { 0 } > }; > > In addition to being more efficient in the common case, I also consider > this version much easier to read and maintain. > > We could certainly spend more effort on supplying and collecting a > single register more efficiently. For instance, we could offer > additional routines for that special case, perhaps in conjunction with a > preparation function that converts a regmap to an indexed-by-regnum > array. However, I wouldn't focus on that too much before actually > making use of it. Note that currently these functions are *always* > called with regnum == -1. > > In fact, it may be more adequate to completely get rid of the parameter > regnum in the regset supply/collect functions. Any reason why we > shouldn't? I think you are right its better off if we leave the single register variants to target specific *-tdep where they can be retrieved using regcache_raw_ supply/collect functions. All other options to get around the loops wont be trivial.