From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19183 invoked by alias); 17 Feb 2006 09:24:54 -0000 Received: (qmail 19175 invoked by uid 22791); 17 Feb 2006 09:24:54 -0000 X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Feb 2006 09:24:49 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 29025) id 6D3214B4098; Fri, 17 Feb 2006 10:24:46 +0100 (CET) Date: Fri, 17 Feb 2006 09:24:00 -0000 From: Zdenek Dvorak To: Roger Sayle Cc: gcc-patches@gcc.gnu.org Subject: Re: Patch ping Message-ID: <20060217092446.GA18805@atrey.karlin.mff.cuni.cz> References: <20060216155808.GA7757@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2006-02/txt/msg01404.txt.bz2 Hello, > On Thu, 16 Feb 2006, Zdenek Dvorak wrote: > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00676.html > > -- patch to improve the functions to work affine combinations; this > > patch blocks further ivopts cleanups (in particular, it keeps > > decl_rtl_to_reset alive -- I would really like to get rid of this > > ugly hack). > > > I'm a bit uncomfortable with the code duplication introduced by your > new double_int structure. what code duplication? It just introduces a few simple wrapper functions, so that the manipulation is simpler and the code is cleaner. > Similar double word arithmetic routines > are already duplicated in the tree-ssa optimizers. The middle-end > handling of TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW and representation > of INTEGER_CST, REAL_CST, CONST_INT and CONST_DOUBLE in trees and > RTL are already "weeping sores" in GCC's infrastructure. Rather > than add another set of hacks, or get embroiled in the inevitable > clean-up, might I recommend using HOST_WIDE_INT pairs for the time > being? I am really uncomfortable with this suggestion :-( Yep, it is certainly possible; however, keeping two parts of the same object separate strikes me as wrong design. > Entangling your iv-opts clean-ups with the nightmare of GCC's > multi-precision integer handling might result in delaying your > changes until 4.3 or later :-( For example it isn't clear whether > your new structure is a constructive step in the right direction. Well, as long as ivopts must handle the case of short and long integers separately, it is very hard to make any progress in it. Zdenek