From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11902 invoked by alias); 2 Feb 2015 18:32:22 -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 11892 invoked by uid 89); 2 Feb 2015 18:32:21 -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, 02 Feb 2015 18:32:20 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t12IWGwc027109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 2 Feb 2015 13:32:17 -0500 Received: from [10.3.113.3] ([10.3.113.3]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t12IWGSk015905; Mon, 2 Feb 2015 13:32:16 -0500 Message-ID: <54CFC2AF.1040405@redhat.com> Date: Mon, 02 Feb 2015 18:32: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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00078.txt.bz2 On 02/02/15 01:57, Richard Biener wrote: >> >> The nice thing about wrapping the result inside a convert is the types for >> the inner operations will propagate from the type of the inner operands, >> which is exactly what we want. We then remove the hack assigning type and >> instead the original type will be used for the outermost convert. > > It's not even a hack but wrong ;) Correct supported syntax is > > + (with { tree type0 = TREE_TYPE (@0); } > + (convert:type0 (bit_and (inner_op @0 @1) (convert @3))))))) > > Thus whenever the generator cannot auto-guess a type (or would guess > the wrong one) you can explicitely specify a type to convert to. I found that explicit types were ignored in some cases. It was frustrating to say the least. But I think I've got this part doing what I want without the hack. > > Why do you restrict this to GENERIC? On GIMPLE you'd eventually > want to impose some single-use constraints as the result with all > the conversions won't really be unconditionally "better"? That was strictly because of the mismatch between the resulting type and how it was later used. That restriction shouldn't be needed anymore. Jeff