From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5360 invoked by alias); 6 Feb 2015 17:41:40 -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 5348 invoked by uid 89); 6 Feb 2015 17:41:40 -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,SPF_PASS,T_RP_MATCHES_RCVD 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; Fri, 06 Feb 2015 17:41:39 +0000 Received: from KLMAIL01.kl.imgtec.org (unknown [192.168.5.35]) by Websense Email Security Gateway with ESMTPS id AFCE812CEDA9F; Fri, 6 Feb 2015 17:41:33 +0000 (GMT) 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; Fri, 6 Feb 2015 17:41:36 +0000 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; Fri, 6 Feb 2015 17:41:36 +0000 From: Matthew Fortune To: Mike Stump , "Maciej W. Rozycki" CC: Petar Jovanovic , "gcc-patches@gcc.gnu.org" , "Moore, Catherine (Catherine_Moore@mentor.com)" Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro Date: Fri, 06 Feb 2015 17:41:00 -0000 Message-ID: <6D39441BF12EF246A7ABCE6654B0235320FCB901@LEMAIL01.le.imgtec.org> References: <003e01d04179$ccc38bc0$664aa340$@rt-rk.com> <6D39441BF12EF246A7ABCE6654B0235320FCA3F1@LEMAIL01.le.imgtec.org> <6D39441BF12EF246A7ABCE6654B0235320FCAD06@LEMAIL01.le.imgtec.org> In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00416.txt.bz2 Mike Stump writes: > On Feb 6, 2015, at 4:23 AM, Maciej W. Rozycki > wrote: > > This consideration made me realise I've had a patch outstanding for > > some > > 10 years to convert all the `BAL x' instructions there to `BLTZAL $0, > x'. > > This has always been a good idea in case implementations recognised > > the special case and avoided involving branch prediction, and I > > believe it has become even more apparent with r6 calling it NAL. >=20 > Ick, no. What part of this are you referring to? NAL (bizarre name or not) is the least intrusive way to obtain the PC on MIPS <=3D R5. The use of BAL for this, albeit common, has a high risk of affecting hardware optimisations like return predictors by introducing a call that will never return. This is a change that I am also planning to propagate to as many projects as possible. If you can see a problem with using BLTZAL for this purpose please could you explain as it may have been overlooked? Thanks, Matthew