From patchwork Sat Nov 2 11:06:01 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 287971 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id C5D592C00E0 for ; Sat, 2 Nov 2013 22:06:12 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; q=dns; s=default; b=ohjK3BOCqMql4+bc4GlOJUeNX716uSelQHpgjKX3AN5HlrdKty eitiVMuZcUV6PidWA1cpO1X3AiXDDrycS2k9uT0P3quyGF/Jn/fbMAEDFUr7E4X/ QodlJLCvU5MkLu23WHUMTf0KG67y0xCwL74pH0RogdW8x3nLDs33Enddk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:mime-version:content-type; s= default; bh=Sfoz+QeeybgvUgSziqsT951m1Wo=; b=v3nmh3LQcwjGlvujJUuO +2TdsE9Z1ktvfvKGihXs9iST21c/VpQc+aZ82IfC6Z3i6K730pIx8a74O0CpxJAW FijJHwXMz3m2GCPniCBApUKdVEKcTZnw7hXiDokV4NG7AvmHNIpQ+ykgFxdkuJNE Mgct9gLQrKhoKyVhAb7zehA= Received: (qmail 21821 invoked by alias); 2 Nov 2013 11:06:07 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 21804 invoked by uid 89); 2 Nov 2013 11:06:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f177.google.com Received: from mail-we0-f177.google.com (HELO mail-we0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 02 Nov 2013 11:06:05 +0000 Received: by mail-we0-f177.google.com with SMTP id x55so451636wes.36 for ; Sat, 02 Nov 2013 04:06:02 -0700 (PDT) X-Received: by 10.180.38.99 with SMTP id f3mr5379497wik.40.1383390362396; Sat, 02 Nov 2013 04:06:02 -0700 (PDT) Received: from localhost ([2.28.235.51]) by mx.google.com with ESMTPSA id td6sm16256891wic.10.2013.11.02.04.06.01 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Sat, 02 Nov 2013 04:06:01 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, zadeck@naturalbridge.com, mikestump@comcast.net, rguenther@suse.de, rdsandiford@googlemail.com Cc: zadeck@naturalbridge.com, mikestump@comcast.net, rguenther@suse.de Subject: [wide-int] doloop fixes Date: Sat, 02 Nov 2013 11:06:01 +0000 Message-ID: <87y557jc6e.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 The first part of this is a simple type mismatch -- get_max_loop_iterations returns a widest_int aka max_wide_int -- and I'd have installed it as obvious. The second part isn't as obvious though. The old code stored the maximum iterations as: if (!get_max_loop_iterations (loop, &iter) || !iter.fits_shwi ()) iterations_max = const0_rtx; else iterations_max = GEN_INT (iter.to_shwi ()); and the new code uses: if (!get_max_loop_iterations (loop, &iter) || !wi::fits_shwi_p (iter)) iterations_max = const0_rtx; else iterations_max = immed_wide_int_const (iter, mode); which includes an extra canonicalisation. I agree it would be good to do that in principle, but I'm not sure it copes correctly with the case where the loop iterates 1 << GET_MODE_PRECISION (mode) times. Plus I think the real fix would be to avoid the host dependence altogether, i.e. get rid of the fits_shwi_p too. As it stands, this breaks bfin-elf's pattern, which has: /* Due to limitations in the hardware (an initial loop count of 0 does not loop 2^32 times) we must avoid to generate a hardware loops when we cannot rule out this case. */ if (!flag_unsafe_loop_optimizations && (unsigned HOST_WIDE_INT) INTVAL (operands[2]) >= 0xFFFFFFFF) FAIL; With the sign-extending conversion, this now triggers more often than it was supposed to. Since the old "GEN_INT (iter.to_shwi ());" works verbatim in wide-int too, and since we still use that form in the doloop_begin code, I think we should just back the immed_wide_int_const out. Tested on powerpc64-linux-gnu and x86_64-linux-gnu. It fixes some unwanted testsuite changes in bfin-elf. OK to install? Thanks, Richard Index: gcc/loop-doloop.c =================================================================== --- gcc/loop-doloop.c 2013-11-02 10:49:37.463178153 +0000 +++ gcc/loop-doloop.c 2013-11-02 10:49:55.927314661 +0000 @@ -549,7 +549,7 @@ doloop_modify (struct loop *loop, struct { rtx init; unsigned level = get_loop_level (loop) + 1; - wide_int iter; + widest_int iter; rtx iter_rtx; if (!get_max_loop_iterations (loop, &iter) @@ -673,7 +673,7 @@ doloop_optimize (struct loop *loop) || !wi::fits_shwi_p (iter)) iterations_max = const0_rtx; else - iterations_max = immed_wide_int_const (iter, mode); + iterations_max = GEN_INT (iter.to_shwi ()); level = get_loop_level (loop) + 1; /* Generate looping insn. If the pattern FAILs then give up trying