From patchwork Thu Jan 3 08:34:55 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 209194 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]) by ozlabs.org (Postfix) with SMTP id 9FF462C008F for ; Thu, 3 Jan 2013 19:35:20 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1357806921; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=bwY3ZiwmEQV5sHWcHWjf pbjyUls=; b=hQwq7zn9NeKIoqdwvhKuw7x3x/EE5eMYIcveEJOmwK6wHZhGZBqi kbdKOHCDJT/HkDRnFHFJKAXS2KNhyjH9FMeeXeMoD52be+D5bjm4qdAl/s30Tvex YEHkkbytA/jSock5i1kPsZeH5D2zCeCkSFOwUaTXGgk/43CsT9JCcG8= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=xQyLjgvT8ucTF1C5WnNFNIslwK1XMYWCJkstZV7B3XBU8Yw6xh5ukW2iUMtJQ8 aTGsM36gLubYtICC8avdlCfYmerln2Z/CDixNZa34W3osw43OblXkmkwCJX/0UAO SaH8/xsA5plMsQXpDUBvSQoRLQdnGIwyO4SwlIMrjD3lg=; Received: (qmail 27018 invoked by alias); 3 Jan 2013 08:35:13 -0000 Received: (qmail 26896 invoked by uid 22791); 3 Jan 2013 08:35:12 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_SPAMHAUS_DROP, RCVD_IN_DNSWL_HI, SPF_HELO_PASS, T_RP_MATCHES_RCVD 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; Thu, 03 Jan 2013 08:35:01 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r038Yx20026834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Jan 2013 03:34:59 -0500 Received: from zalov.redhat.com (vpn1-4-31.ams2.redhat.com [10.36.4.31]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r038YvXx023048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Jan 2013 03:34:58 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r038YuMG008511; Thu, 3 Jan 2013 09:34:56 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r038Ytc7008510; Thu, 3 Jan 2013 09:34:55 +0100 Date: Thu, 3 Jan 2013 09:34:55 +0100 From: Jakub Jelinek To: Richard Biener , Zdenek Dvorak , Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix iv_number_of_iterations (PR rtl-optimization/55838) Message-ID: <20130103083455.GF7269@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 Hi! When one (or both) IVs have extend_mode wider than mode, but step doesn't fit into mode (the IV is (subreg:MODE (plus:EXTEND_MODE base (mult:EXTEND_MODE i step)) lowpart) ), such as for EXTEND_MODE SImode, MODE QImode and step e.g. 129, 128, 256 or 517, iv_number_of_iterations can create invalid rtl. I think it is safe to just use the lowpart subreg of the step. The second hunk isn't enough, we use iv0.step resp. iv1.step directly in several other places in the routine, and the first hunk IMHO isn't enough either, if for the above extend_mode SI and mode QI iv1.step is 128, the first hunk will make -128 out of it, but then we negate it and get step 128 out of it again, not valid QImode CONST_INT, and use it e.g. as argument to UMOD. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? Or shall we just punt (either as done by H.J. in the PR, or in iv_number_of_iterations if the steps aren't valid mode CONST_INTs)? 2013-01-03 Jakub Jelinek PR rtl-optimization/55838 * loop-iv.c (iv_number_of_iterations): Call lowpart_subreg on iv0.step, iv1.step and step. * gcc.dg/pr55838.c: New test. Jakub --- gcc/loop-iv.c.jj 2012-10-22 08:42:25.000000000 +0200 +++ gcc/loop-iv.c 2013-01-02 09:17:42.215591646 +0100 @@ -2406,6 +2406,9 @@ iv_number_of_iterations (struct loop *lo iv1.step = const0_rtx; } + iv0.step = lowpart_subreg (mode, iv0.step, comp_mode); + iv1.step = lowpart_subreg (mode, iv1.step, comp_mode); + /* This is either infinite loop or the one that ends immediately, depending on initial values. Unswitching should remove this kind of conditions. */ if (iv0.step == const0_rtx && iv1.step == const0_rtx) @@ -2516,6 +2519,7 @@ iv_number_of_iterations (struct loop *lo step = simplify_gen_unary (NEG, comp_mode, iv1.step, comp_mode); else step = iv0.step; + step = lowpart_subreg (mode, step, comp_mode); delta = simplify_gen_binary (MINUS, comp_mode, iv1.base, iv0.base); delta = lowpart_subreg (mode, delta, comp_mode); delta = simplify_gen_binary (UMOD, mode, delta, step); --- gcc/testsuite/gcc.dg/pr55838.c.jj 2012-11-17 15:43:17.572007394 +0100 +++ gcc/testsuite/gcc.dg/pr55838.c 2013-01-02 21:09:55.726580313 +0100 @@ -0,0 +1,13 @@ +/* PR rtl-optimization/55838 */ +/* { dg-do compile } */ +/* { dg-options "-O2 -funroll-loops" } */ + +int a; +unsigned char c; + +void +f (void) +{ + while (c++ < 2) + c = a += 129; +}