From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21288 invoked by alias); 3 Feb 2015 11:39:58 -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 21273 invoked by uid 89); 3 Feb 2015 11:39:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 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-f169.google.com Received: from mail-we0-f169.google.com (HELO mail-we0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 03 Feb 2015 11:39:56 +0000 Received: by mail-we0-f169.google.com with SMTP id u56so44438884wes.0 for ; Tue, 03 Feb 2015 03:39:53 -0800 (PST) X-Received: by 10.180.107.164 with SMTP id hd4mr34089534wib.7.1422963593717; Tue, 03 Feb 2015 03:39:53 -0800 (PST) Received: from android-4c5a376a18c0e957.fritz.box (p5B0E4719.dip0.t-ipconnect.de. [91.14.71.25]) by mx.google.com with ESMTPSA id hd5sm3770644wib.21.2015.02.03.03.39.52 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Feb 2015 03:39:52 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <54CFC2AF.1040405@redhat.com> References: <54CC560B.8080200@redhat.com> <54CDBDC6.3050000@redhat.com> <54CFC2AF.1040405@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing From: Richard Biener Date: Tue, 03 Feb 2015 11:39:00 -0000 To: Jeff Law CC: Joseph Myers ,GCC Patches Message-ID: <8B8165F1-1BF4-41EA-B680-D2C890D36C5B@gmail.com> X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00128.txt.bz2 On February 2, 2015 7:32:15 PM CET, Jeff Law wrote: >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. Huh, that would be a bug. Do you have a pattern where that happens? Richard. 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