From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38747 invoked by alias); 20 Aug 2015 21:42:34 -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 38735 invoked by uid 89); 20 Aug 2015 21:42:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Aug 2015 21:42:32 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id 3943B459DC55; Thu, 20 Aug 2015 22:42:26 +0100 (IST) Received: from LEMAIL01.le.imgtec.org (192.168.152.62) by KLMAIL01.kl.imgtec.org (192.168.5.35) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 20 Aug 2015 22:42:30 +0100 Received: from LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9]) by LEMAIL01.le.imgtec.org ([fe80::5ae:ee16:f4b9:cda9%17]) with mapi id 14.03.0210.002; Thu, 20 Aug 2015 22:42:29 +0100 From: Matthew Fortune To: Richard Sandiford , Robert Suchanek CC: "Catherine_Moore@mentor.com" , "gcc-patches@gcc.gnu.org" Subject: RE: [PATCH] Disable -mbranch-likely for -Os when targetting generic architecture Date: Thu, 20 Aug 2015 21:52:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235321238501@LEMAIL01.le.imgtec.org> References: <87y4h5iuwd.fsf@googlemail.com> In-Reply-To: <87y4h5iuwd.fsf@googlemail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01260.txt.bz2 Richard Sandiford writes: > Robert Suchanek writes: > > The patch below disables generation of the branch likely instructions f= or -Os > > but only for generic architecture. The branch likely may result in some > > code size reduction but the cost of running the code on R6 core is sign= ificant. >=20 > How about instead splitting PTF_AVOID_BRANCHLIKELY into > PTF_AVOID_BRANCHLIKELY_SPEED and PTF_AVOID_BRANCHLIKELY_SIZE? > We could have PTF_AVOID_BRANCHLIKELY_ALWAYS as an OR of the two. This sounds OK and is nicer. > Anything that does string ops on the architecture is suspicious :-) You can blame me for this. I advocated the string comparison approach as I= had to do the same thing in gas IIRC for some feature and couldn't think of anythi= ng better to suggest. Thanks, Matthew