From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2057.outbound.protection.outlook.com [40.107.7.57]) by sourceware.org (Postfix) with ESMTPS id 2B8CB3858D1E for ; Mon, 30 Jan 2023 14:17:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2B8CB3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KSo1rvKoTFeR/6duCoAiIx6vu+GCV0KsS1RsvA+gCrM=; b=QESW2G1YVbPx49VRJkfrFmtns23JGZs+VBc5pO0pE4u2sA2XGlB4VauhmHfHnE+7z+RSmMPxCgbN+P4y3KlWseMQ9m6ZabuaXNHvjgAWWgnDBfUOG5aqtcFv2bwtiYADMxpAnVgJTs+6NgNAbeuumMvzNOPu8TREt9TNCNlHkSw= Received: from AM6PR10CA0104.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::45) by DBBPR08MB6090.eurprd08.prod.outlook.com (2603:10a6:10:208::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.36; Mon, 30 Jan 2023 14:17:33 +0000 Received: from AM7EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::87) by AM6PR10CA0104.outlook.office365.com (2603:10a6:209:8c::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.36 via Frontend Transport; Mon, 30 Jan 2023 14:17:33 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM7EUR03FT060.mail.protection.outlook.com (100.127.140.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.21 via Frontend Transport; Mon, 30 Jan 2023 14:17:33 +0000 Received: ("Tessian outbound 43b0faad5a68:v132"); Mon, 30 Jan 2023 14:17:33 +0000 X-CR-MTA-TID: 64aa7808 Received: from e566e4965cea.3 by 64aa7808-outbound-1.mta.getcheckrecipient.com id E5994029-0400-48DE-8631-0C35B373016C.1; Mon, 30 Jan 2023 14:17:23 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e566e4965cea.3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Jan 2023 14:17:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S4WA2bM+V5KEoyEejaB41RXK0O5JL2JzefN9MnPpCJaZtevIcOUeP7DCQ/042GPUYv7hIoOfvYVE/BrjyOY3FR1x9oMnkS+hwVwl+Jyp1HNCW9aDL3LGE6mhg8ygln4JAvAY8EgNCtQmCDFYJPr9iHWuq8iFT6HwJ2stDTIKha9Np3/zeLeQgy40HihYQ99R5f9p+y6qHdUNHaVth8Tfo4bTsUqRddqW0QkI2LgYBRjaQVaY/AIHRnyjFY03Ik7MAEtjzEN+mBZh5VewDiUbG1o1J1fgVCQAMtEUOHeNCr4bkSyVvbTJujmShDjDbS+5ccBzJKZbpJd+lqa044Z7rQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KSo1rvKoTFeR/6duCoAiIx6vu+GCV0KsS1RsvA+gCrM=; b=R0vzhn/Y7zuT340ZhqCTcKdE7HKQcnkgRKczcM4JNeYaCbVLa2y/E8eZg0L8Sr1x2VFE0UMndpu3BpL/sAsYfOPLk4altFuysNDRE7dWY5psjlSV0XtN2v3xXmg5e7hVCPBfhyz9L7thYJx4XO7vkQVF8+xa0v2yJYj9N93jH0OXRGki/LqeHCNugTbampk48hGBET37ZDvbt8vsghERmhpT33nO7b6Eo316TgjVgzTIzcaBFKuODGVkj4gNeuVmHPychwDBztU9DVTOw8XVrXCI7YsLWLfDxKgXwmMDXeoJqbTpMMckxxwxAb6OjL2yCVi+l7RIz9VbI+BywqRH0g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KSo1rvKoTFeR/6duCoAiIx6vu+GCV0KsS1RsvA+gCrM=; b=QESW2G1YVbPx49VRJkfrFmtns23JGZs+VBc5pO0pE4u2sA2XGlB4VauhmHfHnE+7z+RSmMPxCgbN+P4y3KlWseMQ9m6ZabuaXNHvjgAWWgnDBfUOG5aqtcFv2bwtiYADMxpAnVgJTs+6NgNAbeuumMvzNOPu8TREt9TNCNlHkSw= Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by PAVPR08MB9403.eurprd08.prod.outlook.com (2603:10a6:102:300::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6043.33; Mon, 30 Jan 2023 14:17:19 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::7e84:c35c:e966:c886]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::7e84:c35c:e966:c886%8]) with mapi id 15.20.6043.036; Mon, 30 Jan 2023 14:17:19 +0000 From: Tamar Christina To: Richard Sandiford CC: "gcc-patches@gcc.gnu.org" , nd , Richard Earnshaw , Marcus Shawcroft , Kyrylo Tkachov Subject: RE: [PATCH]AArch64: Fix codegen regressions around tbz. Thread-Topic: [PATCH]AArch64: Fix codegen regressions around tbz. Thread-Index: AQHZMjuhhqTu5tvGUkSWiEMKtTF34a6yMJ7WgATDnbA= Date: Mon, 30 Jan 2023 14:17:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 9894F513E3CA3B45893FEC195D408F9F.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: VI1PR08MB5325:EE_|PAVPR08MB9403:EE_|AM7EUR03FT060:EE_|DBBPR08MB6090:EE_ X-MS-Office365-Filtering-Correlation-Id: cff7b6c0-9435-4ce0-bdbb-08db02ccbb0f x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: Z4nvap4XkI3HcAJijDnJry0NStJ1dN0Ksz33da0MQX/yj9DBTLbE8NsqQdAIw9NhNmRFEkS+ZwKqL+6froOXUK+K3uvxU1VXUuEotl3sodQN/WxpOMLayjrRjir92pn/moPC5GoRoNTQByYro3TA72q8TcdRwGbPHPxZehcPE1AaUY+9rp3VL/TeQ4LJTn1Z7aKi59loLkFBVBfFA66xWFxs31tdrOfZarcAQ39tNitf/EZI3CdCvThN7cpLwt3R9IlU3VGz3TUM3cP5wwxyRtyM6ygwLwqA2EFUu13z0ExGuJOw2YYu5DMD/EwFd34JyJm/JmyNeFzSmMzjPpSXb2DCKez2OhD0IFo8ryY8+wOhjcCjTF5oJ3el8/S4q8Bkh7WO7GsrVW9AsRcmf2WOJfLUWp7/VpjBJcFtd9hsRbcLYeRPAC5lmIwlaUdjt9AKNpIv75mPrshOzcAIkfTlYxFu9LeJ6yZI10uYIbefeiNYvfVXid2KOlztNMmxAjgfcQM4n3+GE4oh52kb3VMR+Jhr7N99xhiKS5obSEnS3LlxQbFprMzkoEp1Ek00Wvpl+AqexjpqZ95uiG5eLIiX2fmgjzexqBYKEcl/IHJ3T5aHTHNwlA9LkRTOyyMNPYQ6E3W7TO5ccqX7jzBce0Pazgl+EqdR61rGrtE9fhHTXT1o8HbXyUTYs3aI+S9tahfZUMhTiiP+GmbUsG1J7fg4ufa+fX6bka+xhdV4Yb7N4m2pgJR1fjNU4RV4xvEE279LhKZvGFWID24R8uG6Agx1sA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB5325.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230025)(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(451199018)(83380400001)(86362001)(55016003)(33656002)(38070700005)(38100700002)(122000001)(76116006)(7696005)(71200400001)(2906002)(52536014)(8936002)(41300700001)(5660300002)(6636002)(54906003)(316002)(6862004)(64756008)(8676002)(66446008)(66946007)(966005)(66556008)(66476007)(84970400001)(53546011)(26005)(4326008)(186003)(9686003)(478600001)(6506007);DIR:OUT;SFP:1101; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PAVPR08MB9403 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM7EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 0b8110be-9e0b-44a0-851c-08db02ccb279 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pxaLIEwbrrgmTzhTWfKGj/IcvKeHaTBJvvPfEbRw07l5K0JzmHQd5lda1iy40dmFURXDt+CAWMeJHVt2PdCFmFcvZG7tf9VLOUm0f1GySSV0Yvz3+jB8l91Kz1TFmN01zE06+pdwAfZ8gtfZcqmluuSQxG8rYK1J3bhwaU7OcOEtrlDk9SRM8PsMCt3ez0DLZWux5sucjQAfo/u3ZYQu0nVO7Zk8YLoJYEcbKK1+Z+CS/AyfJhSM85giDm0JmjnUiCewrCUnUobMCr+o6ZJv5SWQzX22wg//E6FXE8EWQlfgH4FAZnicm89DrjT1M+b0+9eNkgiFwUYMjwZG4mCaV5G4d+7J2JorSoYGpEmqAyH/VjTsLrd7pqKdHovPx98gtSiJkCVmBQP3fNtbFtbrbJfzYldPg+rSY4LNHAf/yf5Snh12B5wEyFZyxOtZ/WUg67JmRep1leF/KLEDqRjbUemWbVRu5BxNeVPQDJBgUafXPYoOhOVeLoxeR5oNi4GCuJY3ZIwbU5K3eGsxnWviMQowtcqMexlFl5X0qIfv1Spx1EKCgGMPm+89IKhHO2tk7SoVyJ6/DA8LAmNwER9pnL4k+X2ll3a5MuC8FOXNCjb5R50H7kfBPZk8y8sqap5Z2jQnc86O1DXez14oMkz9nGZnC6zJqHkvwdQv9Ug/hlUfa80MFhltYhp+Q7cyOwYrOXDrTtflZFOWmrnHlB6yE//cXoYIuJ4nuQazBdSnFAczFdVJnXD9MX3+fCkQO8WerVreYbyz1r7Jj+M7+izITg== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230025)(4636009)(346002)(39860400002)(136003)(376002)(396003)(451199018)(40470700004)(46966006)(36840700001)(83380400001)(84970400001)(7696005)(33656002)(40460700003)(86362001)(40480700001)(55016003)(81166007)(8676002)(36860700001)(356005)(336012)(47076005)(82740400003)(9686003)(186003)(26005)(82310400005)(966005)(5660300002)(53546011)(316002)(6636002)(6506007)(478600001)(54906003)(52536014)(70586007)(70206006)(8936002)(6862004)(41300700001)(4326008)(2906002);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jan 2023 14:17:33.7230 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cff7b6c0-9435-4ce0-bdbb-08db02ccbb0f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM7EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB6090 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,KAM_DMARC_NONE,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > -----Original Message----- > From: Richard Sandiford > Sent: Friday, January 27, 2023 12:26 PM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw > ; Marcus Shawcroft > ; Kyrylo Tkachov > Subject: Re: [PATCH]AArch64: Fix codegen regressions around tbz. >=20 > Tamar Christina writes: > > Hi All, > > > > We were analyzing code quality after recent changes and have noticed > > that the tbz support somehow managed to increase the number of > > branches overall rather than decreased them. > > > > While investigating this we figured out that the problem is that when > > an existing & exists in gimple and the instruction is > > generated because of the range information gotten from the ANDed > > constant that we end up with the situation that you get a NOP AND in th= e > RTL expansion. > > > > This is not a problem as CSE will take care of it normally. The issue= is when > > this original AND was done in a location where PRE or FRE "lift" the > > AND to a different basic block. This triggers a problem when the > > resulting value is not single use. Instead of having an AND and tbz, > > we end up generating an AND + TST + BR if the mode is HI or QI. > > > > This CSE across BB was a problem before but this change made it worse. > > Our branch patterns rely on combine being able to fold AND or > > zero_extends into the instructions. > > > > To work around this (since a proper fix is outside of the scope of > > stage-4) we are limiting the new tbranch optab to only HI and QI mode > > values. This isn't a problem because these two modes are modes for > > which we don't have CBZ support, so they are the problematic cases to > begin with. Additionally booleans are QI. > > > > The second thing we're doing is limiting the only legal bitpos to pos 0= . i.e. > > only the bottom bit. This such that we prevent the double ANDs as > > much as possible. > > > > Now most other cases, i.e. where we had an explicit & in the source > > code are still handled correctly by the anonymous > > (*tb1) > > pattern that was added along with tbranch support. > > > > This means we don't expand the superflous AND here, and while it > > doesn't fix the problem that in the cross BB case we loss tbz, it also = doesn't > make things worse. > > > > With these tweaks we've now reduced the number of insn uniformly as > > originally expected. > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > > > Ok for master? > > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > * config/aarch64/aarch64.md (tbranch_3): Restrict to > SHORT > > and bottom bit only. > > > > gcc/testsuite/ChangeLog: > > > > * gcc.target/aarch64/tbz_2.c: New test. >=20 > Agreed that reducing the scope of the new optimisation seems like a safe > compromise for GCC 13. But could you add a testcase that shows the effec= t > of both changes (reducing the mode selection and the bit selection)? The > test above passes even without the patch. >=20 > It would be good to have a PR tracking this too. I've been trying to isolate a small testcase to include, and it's not been = trivial as GCC will do various transformations on smaller sequences to still do the right = thing. I have various testcase where GCC is doing the wrong thing for the branches= but as soon As my repro for the cases this fixes gets too small problem gets hidden.. >=20 > Personally, I think we should try to get to the stage where gimple does t= he > CSE optimisations we need, and where the tbranch optab can generate a tbz > directly (rather than splitting it apart and hoping that combine will put= it back > together later). Agreed, but that doesn't solve all the problems though. GCC is in general q= uite bad at branch layouts especially wrt. To branch distances. For instance BB rotation doesn= 't take distance into account. And TBZ, CBZ, B have different ranges. Since the distance isn't t= aken into account we end up "optimizing" the branch and then at codegen doing an emergency dista= nce enlargement using a TST + B to replace whatever we optimized too. LLVM does much better in all of these scenarios, so it's likely that the en= tire branch strategy needs an overhaul. https://godbolt.org/z/1dhf7T5he shows some of the mini examples. I can ke= ep trying to make a reproducer for what my patch changes if you'd like, but I don't think it wi= ll be small.. The general problem is the same as in f2 but we introduce it in the cases of f3 as well= (bool), but adding & to a bool will get it trivially optimized out. Thanks, Tamar >=20 > Thanks, > Richard >=20 > > --- inline copy of patch -- > > diff --git a/gcc/config/aarch64/aarch64.md > > b/gcc/config/aarch64/aarch64.md index > > > 2c1367977a68fc8e4289118e07bb61398856791e..aa09e93d85e9628e8944e0349 > 869 > > 7eb9597ef867 100644 > > --- a/gcc/config/aarch64/aarch64.md > > +++ b/gcc/config/aarch64/aarch64.md > > @@ -949,8 +949,8 @@ (define_insn "*cb1" > > > > (define_expand "tbranch_3" > > [(set (pc) (if_then_else > > - (EQL (match_operand:ALLI 0 "register_operand") > > - (match_operand 1 "aarch64_simd_shift_imm_")) > > + (EQL (match_operand:SHORT 0 "register_operand") > > + (match_operand 1 "const0_operand")) > > (label_ref (match_operand 2 "")) > > (pc)))] > > "" > > diff --git a/gcc/testsuite/gcc.target/aarch64/tbz_2.c > > b/gcc/testsuite/gcc.target/aarch64/tbz_2.c > > new file mode 100644 > > index > > > 0000000000000000000000000000000000000000..ec128b58f35276a7c5452685a6 > 5c > > 73f95f2d5f9a > > --- /dev/null > > +++ b/gcc/testsuite/gcc.target/aarch64/tbz_2.c > > @@ -0,0 +1,130 @@ > > +/* { dg-do compile } */ > > +/* { dg-additional-options "-O2 -std=3Dc99 -fno-unwind-tables > > +-fno-asynchronous-unwind-tables" } */ > > +/* { dg-final { check-function-bodies "**" "" "" { target { le } } } > > +} */ > > + > > +#include > > + > > +void h(void); > > + > > +/* > > +** g1: > > +** cbnz w0, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g1(int x) > > +{ > > + if (__builtin_expect (x, 0)) > > + h (); > > +} > > + > > +/* > > +** g2: > > +** tbnz x0, 0, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g2(int x) > > +{ > > + if (__builtin_expect (x & 1, 0)) > > + h (); > > +} > > + > > +/* > > +** g3: > > +** tbnz x0, 3, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g3(int x) > > +{ > > + if (__builtin_expect (x & 8, 0)) > > + h (); > > +} > > + > > +/* > > +** g4: > > +** tbnz w0, #31, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g4(int x) > > +{ > > + if (__builtin_expect (x & (1 << 31), 0)) > > + h (); > > +} > > + > > +/* > > +** g5: > > +** tst w0, 255 > > +** bne .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g5(char x) > > +{ > > + if (__builtin_expect (x, 0)) > > + h (); > > +} > > + > > +/* > > +** g6: > > +** tbnz w0, 0, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g6(char x) > > +{ > > + if (__builtin_expect (x & 1, 0)) > > + h (); > > +} > > + > > +/* > > +** g7: > > +** tst w0, 3 > > +** bne .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g7(char x) > > +{ > > + if (__builtin_expect (x & 3, 0)) > > + h (); > > +} > > + > > +/* > > +** g8: > > +** tbnz w0, 7, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g8(char x) > > +{ > > + if (__builtin_expect (x & (1 << 7), 0)) > > + h (); > > +} > > + > > +/* > > +** g9: > > +** tbnz w0, 0, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g9(bool x) > > +{ > > + if (__builtin_expect (x, 0)) > > + h (); > > +} > > + > > +/* > > +** g10: > > +** tbnz w0, 0, .L[0-9]+ > > +** ret > > +** ... > > +*/ > > +void g10(bool x) > > +{ > > + if (__builtin_expect (x & 1, 0)) > > + h (); > > +} > > +