From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3344 invoked by alias); 6 Jul 2011 15:56:03 -0000 Received: (qmail 3336 invoked by uid 22791); 6 Jul 2011 15:56:02 -0000 X-SWARE-Spam-Status: No, hits=-3.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jul 2011 15:55:48 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id 9499E8ACEB; Wed, 6 Jul 2011 17:55:46 +0200 (CEST) Date: Wed, 06 Jul 2011 15:56:00 -0000 From: Michael Matz To: Richard Sandiford Cc: gcc@gcc.gnu.org Subject: Re: Help with ivopts In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-07/txt/msg00069.txt.bz2 Hi, On Wed, 6 Jul 2011, Richard Sandiford wrote: > > It's only a strict win on targets where the addition in "(q-p) + n" > > can be hidden in either address generation, or combined with other > > arithmetic, or on all targets if (q-p) is a constant. > > Agreed on the constant thing. But is it really valid to account for > address validity in the !address_p case? Well, some targets can hide this addition also in other instructions not necessarily only for accessing memory (e.g. the lea instruction on x86). That has to be described in the cost function. > > So, sometimes the first is better, sometimes just the same, sometimes > > worse :-) Probably the cost function in ivopts could use some > > improvements taking at least autoinc into account. The valid address > > forms (i.e. if reg+reg is as cheap as reg) should be taken into account > > already. > > ...we currently only check for things like reg+reg in the address_p case, > which as discussed, is also the case in which we currently don't apply > this transformation for other reasons. The address_p case is also the > one in which we take auto-increment into account. > > That goes back to the question in the original message about whether > these uses should be treated as addresses. I suppose the answer's > probably "yes", since only a cast is getting in the way. Yes, I think for your example this should be regarded as addresses. > But there's still the separate point that, when not considering > addresses, this transformation doesn't seem to be a win, except > in the constant case. My first example shows that on some targets it can be a win, also in the non-constant case, saving one IV update. That is the case if the use of IVb can be replaced by IVb+somereg for "free". Be that addresses or not. > I suppose what I'm saying is that the: > > if (use->iv->base_object > && cand->iv->base_object > && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0)) > return infinite_cost; > > condition seems to make sense in the !address_p case too. It shouldn't > make things worse, and may make things better. It would make things worse for the above mentioned targets. I actually think this whole special casing of address_p just hides problems elsewhere, namely in the alising machinery (as I hinted, this might actually be solved meanwhile), and certainly in the cost functions of IVopts. If it's really better to not express a certain use of IVb via ((base_b-base_a)+IVa), then the cost function should say so, not some after-the-fact hackery rejecting this transformation a posteriori. If this rejection should still be needed for correctness for the aliasing machinery then it should be limited to that one purpose: avoiding wrong code. It should not be used to avoid generating worse code on some targets. Ciao, Michael.