From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107409 invoked by alias); 13 Nov 2015 15:56:37 -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 107398 invoked by uid 89); 13 Nov 2015 15:56:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Fri, 13 Nov 2015 15:56:36 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 221BC550BA; Fri, 13 Nov 2015 15:56:35 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tADFuXGh001228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 13 Nov 2015 10:56:34 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id tADFuWQn013433; Fri, 13 Nov 2015 16:56:32 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id tADFuUM6013432; Fri, 13 Nov 2015 16:56:30 +0100 Date: Fri, 13 Nov 2015 15:56:00 -0000 From: Jakub Jelinek To: Marek Polacek Cc: Bernd Schmidt , David Malcolm , Jeff Law , Richard Biener , Manuel =?iso-8859-1?B?TPNwZXotSWLh8WV6?= , GCC Patches Subject: Re: [PATCH 0/2] Levenshtein-based suggestions (v3) Message-ID: <20151113155630.GT5675@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <55FB150C.5090105@redhat.com> <1446209267-49800-1-git-send-email-dmalcolm@redhat.com> <56370667.8000005@redhat.com> <1447380516.7830.34.camel@surprise> <20151113065738.GH3185@redhat.com> <1447416968.7830.43.camel@surprise> <20151113151119.GJ3185@redhat.com> <56460555.4010909@redhat.com> <20151113155305.GK3185@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151113155305.GK3185@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01725.txt.bz2 On Fri, Nov 13, 2015 at 04:53:05PM +0100, Marek Polacek wrote: > On Fri, Nov 13, 2015 at 04:44:21PM +0100, Bernd Schmidt wrote: > > On 11/13/2015 04:11 PM, Marek Polacek wrote: > > >Sorry, I changed my mind. Since QUAL_UNION_TYPE is Ada-only thing and > > >we check (RECORD_TYPE || UNION_TYPE) in a lot of places in the C FE, > > >introducing RECORD_OR_UNION_TYPE_P everywhere would unnecessarily slow > > >things down. > > > > I don't think so, the three codes are adjacent so we should be generating > > "(unsigned)(code - RECORD_TYPE) < 3". > > Interesting. Yeah, if we change the RECORD_OR_UNION_TYPE_P macro to this > form, then we don't need a separate version for the C FE. Why? The compiler should do that already, or do you care about -O0 builds or host compilers other than gcc that aren't able to do this? The disadvantage of writing it manually that way is that you need to assert somewhere that the 3 values indeed are consecutive, while when the (host?) compiler performs this optimization, it does that only if they are consecutive, if they are not, the code will be just less efficient. Jakub