From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14054 invoked by alias); 30 Mar 2012 15:41:55 -0000 Received: (qmail 14043 invoked by uid 22791); 30 Mar 2012 15:41:53 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Mar 2012 15:41:08 +0000 Received: by wera1 with SMTP id a1so513180wer.20 for ; Fri, 30 Mar 2012 08:41:07 -0700 (PDT) Received: by 10.180.94.33 with SMTP id cz1mr7562775wib.13.1333122067498; Fri, 30 Mar 2012 08:41:07 -0700 (PDT) Received: from richards-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com. [195.212.29.75]) by mx.google.com with ESMTPS id 6sm7203507wiz.1.2012.03.30.08.41.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Mar 2012 08:41:06 -0700 (PDT) From: Richard Sandiford To: Kenneth Zadeck Mail-Followup-To: Kenneth Zadeck ,gcc-patches , Ian Lance Taylor , Mike Stump , Kenneth Zadeck , avr@gjlay.de, ramana.radhakrishnan@linaro.org, rdsandiford@googlemail.com Cc: gcc-patches , Ian Lance Taylor , Mike Stump , Kenneth Zadeck , avr@gjlay.de, ramana.radhakrishnan@linaro.org Subject: Re: [C Patch]: pr52543 References: <4F67D595.9030700@naturalbridge.com> <4F6881EA.9080306@naturalbridge.com> <4F6889CC.8080302@naturalbridge.com> <4F74CFB3.5090308@naturalbridge.com> <4F75D041.4070206@naturalbridge.com> Date: Fri, 30 Mar 2012 15:41:00 -0000 In-Reply-To: <4F75D041.4070206@naturalbridge.com> (Kenneth Zadeck's message of "Fri, 30 Mar 2012 11:24:49 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg01944.txt.bz2 Kenneth Zadeck writes: >>> + There are two useful preprocessor defines for use by maintainers: >>> + >>> + #define LOG_COSTS >>> + >>> + if you wish to see the actual cost estimates that are being used >>> + for each mode wider than word mode and the cost estimates for zero >>> + extension and the shifts. This can be useful when port maintainers >>> + are tuning insn rtx costs. >>> + >>> + #define FORCE_LOWERING >>> + >>> + if you wish to test the pass with all the transformation forced on. >>> + This can be useful for finding bugs in the transformations. >> Must admit I'm not keen on these kinds of macro, but it's Ian's call. >> >> Idea for the future (i.e. not this patch) is to have a dump file for >> target initialisation. > Imagine my horror when i did all of this as you had privately suggested > and discovered that there was no way to log what i was doing. This is > good enough until someone wants to fix the general problem. > >>> +/* This pass can transform 4 different operations: move, ashift, >>> + lshiftrt, and zero_extend. There is a boolean vector for move >>> + splitting that is indexed by mode and is true for each mode that is >>> + to have its copies split. The other three operations are only done >>> + for one mode so they are only controlled by a single boolean .*/ >> As mentioned privately, whether this is profitable for shifts depends >> to some extent on the shift amount. GCC already supports targets where >> this transformation would be OK for some shift amounts but not others. >> So for shifts, I think this should be an array of HOST_BITS_PER_WIDE_INT >> booleans rather than just one. >> >> More comments below about how this filters through your other changes. > I think that you actually are missing what i am doing with this. I > look at 3 representative values that "should" discover any non > uniformities. If any of them are profitable, i set this bit. Then at > the point where i really have to pull the trigger on a real instance, i > check the shift amount used at that spot to see if the individual shift > is profitable. No, I got that. I just think it's an unnecessary complication. > I did this for two reasons. One of them was that i was a little > concerned that HOST_BITS_PER_WIDE_INT on the smallest host was not as > big as the bitsize of word_word mode on the largest target (it could be > but this knowledge is above my pay grade). Ah, yes, sorry, I meant an array of BITS_PER_WORD booleans. I had HOST_WIDE_INT on the brain after Mike's patch. > The other reason was did not see this as a common operation and > checking it on demand seemed like the winner. But (at least after the other changes I mentioned) these overall booleans cut out only a very small portion of find_decomposable_shift_zext. I.e.: op = SET_SRC (set); if (GET_CODE (op) != ASHIFT && GET_CODE (op) != LSHIFTRT && GET_CODE (op) != ZERO_EXTEND) <-- unified booleans checked here return 0; op_operand = XEXP (op, 0); if (!REG_P (SET_DEST (set)) || !REG_P (op_operand) || HARD_REGISTER_NUM_P (REGNO (SET_DEST (set))) || HARD_REGISTER_NUM_P (REGNO (op_operand)) || !SCALAR_INT_MODE_P (GET_MODE (op))) return 0; if (GET_CODE (op) == ZERO_EXTEND) { if (GET_MODE (op_operand) != word_mode || GET_MODE_BITSIZE (GET_MODE (op)) != 2 * BITS_PER_WORD) return 0; } else /* left or right shift */ { <--- specific booleans checked here if (!CONST_INT_P (XEXP (op, 1)) || INTVAL (XEXP (op, 1)) < BITS_PER_WORD || GET_MODE_BITSIZE (GET_MODE (op_operand)) != 2 * BITS_PER_WORD) return 0; } It seems better (and simpler) not to prejudge which shift amounts are interesting and instead cache the "win or no win" flag for each value. As I say, this is all in the context of this pass not being interesting for modes where the split move is strictly more expensive than the unified move, regardless of shift & zext costs. Richard