From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14281 invoked by alias); 23 Oct 2012 01:58:53 -0000 Received: (qmail 14266 invoked by uid 22791); 23 Oct 2012 01:58:51 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 23 Oct 2012 01:58:42 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q9N1wfTq020027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 22 Oct 2012 21:58:41 -0400 Received: from host2.jankratochvil.net (ovpn-116-77.ams2.redhat.com [10.36.116.77]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q9N1wbEL006361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 21:58:40 -0400 Date: Tue, 23 Oct 2012 01:58:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: Siddhesh Poyarekar , gdb-patches@sourceware.org Subject: Re: [PATCH 0/4] bitpos expansion summary reloaded Message-ID: <20121023015835.GA14007@host2.jankratochvil.net> References: <20120927190053.1e7de264@spoyarek> <20120929173938.GA2987@host2.jankratochvil.net> <20120929181141.GA4009@host2.jankratochvil.net> <20120930065211.GA21118@host2.jankratochvil.net> <20121003184155.03dceed4@spoyarek> <20121003195627.GA17283@host2.jankratochvil.net> <20121004071314.GA4292@host2.jankratochvil.net> <20121021130546.02ea680c@spoyarek> <87y5iygrrk.fsf@fleche.redhat.com> <20121023013438.GA13413@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121023013438.GA13413@host2.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 X-SW-Source: 2012-10/txt/msg00394.txt.bz2 On Tue, 23 Oct 2012 03:34:38 +0200, Jan Kratochvil wrote: > On Mon, 22 Oct 2012 22:45:35 +0200, Tom Tromey wrote: > > The reason I ask is that I'm concerned about our ability to maintain > > this change properly, and I wonder if this would be a cheap way to > > handle the more mechanical aspects. > > Cheap for future reviewing. But more expensive for the initial change. To make clear what is the problem here: Primarily I admit I did not know until recently there is -Wconversion at all. The most easy would be to extend to 64-bit any automvaribles handling TYPE_LENGTH (and some similar fields also being extended to 64-bit). But this would include 64-bit lengths of scalar types which has been considered as both performance wasteful and needless work to change them all. The most difficult work on this patch has been (for me) to always judge whether a type at that place of code has to be always scalar or not. It is only about the autovariables as TYPE_LENGTH itself of scalar types has to be 64-bit already (because that struct type->length field has to be 64-bit for struct/array types). IMO we could extend 64-bit length handling everywhere and nothing happens. But I always expected other maintainers will not accept that as it may have performance impact on various non-x86* slow 32-bit host GDB platforms. IMO there are more serious (=algorighmic complexity ones) performance problems of GDB than some worse constant complexity of 64-bit types. I do not see how to easily measure the performance impact without implementing the full 64-bit extension first (but I also believe more work could be invested in fixing the more serious performance problems than trying to micro-optimize this 32-bit vs. 64-bit autovariables). Maybe there are no concerns about extending even scalars to 64-bit? Regards, Jan