From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21704 invoked by alias); 9 Feb 2015 07:15:17 -0000 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 Received: (qmail 21694 invoked by uid 89); 9 Feb 2015 07:15:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 09 Feb 2015 07:15:15 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t197FCAL028588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 9 Feb 2015 02:15:12 -0500 Received: from [10.3.113.80] (ovpn-113-80.phx2.redhat.com [10.3.113.80]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t197FBEc025339; Mon, 9 Feb 2015 02:15:12 -0500 Message-ID: <54D85E7F.8030201@redhat.com> Date: Mon, 09 Feb 2015 07:15:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Biener CC: Joseph Myers , GCC Patches Subject: Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing References: <54CC560B.8080200@redhat.com> <54CDBDC6.3050000@redhat.com> <54CFC2AF.1040405@redhat.com> <8B8165F1-1BF4-41EA-B680-D2C890D36C5B@gmail.com> In-Reply-To: <8B8165F1-1BF4-41EA-B680-D2C890D36C5B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00505.txt.bz2 On 02/03/15 04:39, Richard Biener wrote: >> I found that explicit types were ignored in some cases. It was >> frustrating to say the least. > > Huh, that would be a bug. Do you have a pattern where that happens? I'll have to recreate them. In the mean time consider something else I'm playing with that causes an odd error from genmatch... /* If we have a narrowing conversion of an arithmetic or logical operation where both are operands widening conversions from the same type as the outer narrowing conversion. Then convert the innermost operands to a suitable unsigned type (to avoid introducing undefined behaviour), perform the operation and convert the result to the desired type. */ (simplify (convert (plus (convert@2 @0) (convert @1))) (if (TREE_TYPE (@0) == TREE_TYPE (@1) && TREE_TYPE (@0) == type && INTEGRAL_TYPE_P (type) && TYPE_PRECISION (TREE_TYPE (@2)) >= TYPE_PRECISION (TREE_TYPE (@0))) (with { tree utype = unsigned_type_for (TREE_TYPE (@0));} (convert (plus (convert:utype @0) (convert:utype @1))))))) So given two narrow operands that get widened, added, and the final result narrowed back down to the original operand types. Replace with convert the operands to an unsigned type (of same size as the operand), operate on them and convert to the final desired type. This happens to fix 47477 (P2 regression). Works perfectly for the testcase. Of course we'd like to extend that to other operators... So, adding the obvious for iterator... (for op (plus minus) (simplify (convert (op (convert@2 @0) (convert @1))) (if (TREE_TYPE (@0) == TREE_TYPE (@1) && TREE_TYPE (@0) == type && INTEGRAL_TYPE_P (type) && TYPE_PRECISION (TREE_TYPE (@2)) >= TYPE_PRECISION (TREE_TYPE (@0))) (with { tree utype = unsigned_type_for (TREE_TYPE (@0));} (convert (op (convert:utype @0) (convert:utype @1))))))) Which causes genmatch to barf: build/genmatch --gimple /home/gcc/GIT-2/gcc/gcc/match.pd \ > tmp-gimple-match.c genmatch: two conversions in a row Not only does genmatch barf, it doesn't give any indication what part of the .pd file it found objectionable.