From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150071.outbound.protection.outlook.com [40.107.15.71]) by sourceware.org (Postfix) with ESMTPS id 1D25B3854156 for ; Fri, 30 Sep 2022 12:49:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1D25B3854156 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=h+8gToXM6i4Rhum686voQXukORMt1/xX74qLyQRSyu06hRJsf6eGpIMzzUMbFpxBIrK1RQFANe1w3EM+wCvSYf9famjA+Opn0cdkjre0uukwBJ5iGN3HhnQ2XqOhrwnWOSEFhVuPVf8N+NBAKnkJyOKJS0NcGooU5wEf+3VB7TUeXlXCTptlsVDs49l6qpTajVa+wUT/cD0zXV/Rk0Fv4CK5wxy/BczSDXFCAre0GTOuUzvwgikYVfSalBG2JD07/nP7DYsuKnzhgpEFOhBqaZvy13idiY6rcvNX6zMWllLmcUHu/HFiD195tminmX8SGM7727c1GMKMg2uhJoETDQ== ARC-Message-Signature: i=2; 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=et0N/a7pXyBRSLsJK68Gld7p+4V2hMRKTsRPD5TaTd4=; b=EPelm/s7nkOOrpmKoxp585RArfbZK/R1cM4fZ0nq7GiC/q4My3UcJtHBf9QHjbBRVYrZSNffRCsDgGGlwFU3U9D/dzA2vzJUa84M7GkGZ+wsFJ9OZST1H1W8e4nLGvKCfngqNfp5LaN1iB28fFFCG0e6nee7ePptq0PIwye/loAU8pxbG3a1WpgjB3DP+sSOSz5Cf23ZM3DsB9CXCOsc5Kt1M4Koa+21yAN4fJwcqGvAbTGDwIJUK+ZPfW+SsJbw7To1mJZpXJSQiYBCgLojTwtbulT95NGw21mPFpWZ852fqkY0inmVGEACd9lJZMmU6pPO5t1FOematJnx3yhHaA== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=gcc.gnu.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=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=et0N/a7pXyBRSLsJK68Gld7p+4V2hMRKTsRPD5TaTd4=; b=emJw7Jm/ajqaoi22G9LA8wlytST6ich0VrXa6yIreERBJRzS7nkHI60ENlMGNHMDykkVHe8kXW+9xZkpM9lI/Qtoo8xcZUgpAee+36BeFY7/oSYi66YTAs90ZNwRCqkAgCXh4co/P8eBJkzj/86/xHqlkGQC3gPpfPabD5fhLsY= Received: from AM5PR0301CA0036.eurprd03.prod.outlook.com (2603:10a6:206:14::49) by DU0PR08MB9677.eurprd08.prod.outlook.com (2603:10a6:10:447::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Fri, 30 Sep 2022 12:48:59 +0000 Received: from VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:14:cafe::89) by AM5PR0301CA0036.outlook.office365.com (2603:10a6:206:14::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.17 via Frontend Transport; Fri, 30 Sep 2022 12:48:59 +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 VE1EUR03FT062.mail.protection.outlook.com (10.152.18.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.17 via Frontend Transport; Fri, 30 Sep 2022 12:48:59 +0000 Received: ("Tessian outbound 937eed45f6ed:v128"); Fri, 30 Sep 2022 12:48:59 +0000 X-CR-MTA-TID: 64aa7808 Received: from 73589799cfc0.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 128B33C0-1D41-43E7-8790-BBC4C104D4F0.1; Fri, 30 Sep 2022 12:48:52 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 73589799cfc0.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 30 Sep 2022 12:48:52 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PxhzBlG/IW91RM+fEEwuzuD+LPuKkyYfrz4M0vAGD2vhNg8UtH7Cldyh/9muvLkjbHFCLjTyfbSqPM3y24llJMsRrtANBZovxxklIkLHOpFypGNiEejeqoJLlhowm40qY2fnYywyZvbL9nmcD1oqaMxOF1JH0LtnfsOutFVMcJU5COco/X7lQQqGhe7mKnGOpfreaUQtKOR3dt5hvAa511ONDtKeX0y9ZTxCYPmkcKqgzceg3TvqOIpBC/elqLjfmtyIB7QCK15cZGND4cy8OzMQBXiHDvH3qkLF3kJJZH92WnN1oZiislJFa5VkiEz4y2YhSMI1Mnd62UR3EZqPWg== 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=et0N/a7pXyBRSLsJK68Gld7p+4V2hMRKTsRPD5TaTd4=; b=Jk/yE7nqYkcLx80ay1N/qKKRQpYNaxDoDjQBMZwV5sq1fE/xm8uwA8iUopJm9+gfxDcp+EUQBzNiSaENPQX7mVy+nP4762/RS5xUSqzcTnqKeIYTxRVsVdwivWYWajXqOlXAbU+ULk7+0PVqlflekNrFKAmBNgROd8vHVO8VIsnqvKYGFgEmGZo8PoBNcbXo1RTuGRmkRUfIoyuwoe3Oc4v3jIuix+Km97OfcYrMOJtjPdMxNhBUOZgTHDcHT11SdFd4tJ9uIhsNHfCxdIUH5yjDS906DCvGCS3LTybARKDY0x6kGoIqUcBIZbChpMXWE9ra0rv0XClaEQOxA4kWtg== 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=et0N/a7pXyBRSLsJK68Gld7p+4V2hMRKTsRPD5TaTd4=; b=emJw7Jm/ajqaoi22G9LA8wlytST6ich0VrXa6yIreERBJRzS7nkHI60ENlMGNHMDykkVHe8kXW+9xZkpM9lI/Qtoo8xcZUgpAee+36BeFY7/oSYi66YTAs90ZNwRCqkAgCXh4co/P8eBJkzj/86/xHqlkGQC3gPpfPabD5fhLsY= Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by AS8PR08MB7943.eurprd08.prod.outlook.com (2603:10a6:20b:53b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23; Fri, 30 Sep 2022 12:48:50 +0000 Received: from VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40]) by VI1PR08MB5325.eurprd08.prod.outlook.com ([fe80::6529:66e5:e7d4:1a40%4]) with mapi id 15.20.5676.023; Fri, 30 Sep 2022 12:48:49 +0000 From: Tamar Christina To: Richard Biener CC: Richard Sandiford , Tamar Christina via Gcc-patches , nd , Jeff Law Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend Thread-Topic: [PATCH 1/2]middle-end: RFC: On expansion of conditional branches, give hint if argument is a truth type to backend Thread-Index: AQHYzy5cPtP/U576lE6Yh3eQBn/QMK3xiPyAgAAF5FCAAAoggIAAAUohgANeuPmAACaxAIABECd3gAAA3gCAAArogIAADeOAgAFOFmCAABdsfYAAAasggAAD8PyAAAcNMIAAEXKAgAALrXCAAA8iAIAADJFw Date: Fri, 30 Sep 2022 12:48:49 +0000 Message-ID: References: <8873DC9F-F868-458D-9AD6-90DDC5465057@suse.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: FC992BA54C721C47B82A6DF8BCE690C2.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_|AS8PR08MB7943:EE_|VE1EUR03FT062:EE_|DU0PR08MB9677:EE_ X-MS-Office365-Filtering-Correlation-Id: ff473e8c-f414-4c7e-71fb-08daa2e22500 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: dS8e/h7BaBXE98SOdZn/QYmVRjav/phzjjnZtnmcvoD+PLg+0IQIhpX7j2728+di7OqV3Mb0yPQyAMg4ISsD/AHmWUi37oJmcWg7HHh7LD9WNrS73PCLNRo1cWPbcqnkbQamUY23zDNV9KBjW42EQjQ68VN1s4jgZ90OhBkkhmfUCL11Z/Yx6IGuZHXouvER95ce2qrljJUMrZKnIQfDQcmtqg9jMhUEwI5ZqL/c/PmEyVeOAKJ588n1/ytOosqts2jytWJguuUCcirS0wjt5GIcDHeIlM7izE6gz5V+Hburh2yRnVEkvv+jAFuO6r3erZ+iTe53UX1lLVJh0E3pInv9B+pBixe3QQxjefsH2pEY626tAXppAqrOMowYwn5XnRuOnc+whjHE1nS6M/juWHXhaU97XfPVyy4aGZuUJMukXKpo2ndZwrtvGcs+fTx7w512a2oNPk67a9VQKt0mwLIaP0uD0Eu2Fs9QJZY1wMyHs/W3aN6Q1ezc26WsinZtny6r9yo//hwrnc88OGuPRbmY2DvozpjVQRsx1GJ3GoBIOFcLcEbWZ/Y9jAEPndXRzrMILYnbMu0SOmfu5jTeKICCXVC4cXBjNZcGVPO/G2s/I7tTAxg6PgFolE3dtxhvjpax9H3dl3UkvyaETxNStJWHgKKjO1iSnd+TdGUnv9jWHUJ07xhD37iPRVppmT+JogZg8I8uL+C51Kw7AHQNahGyTekzfcseqkmhhbyyFwCJlE0LpwwRYLGx3oQaWzWNEtCovhsA9OweqmbrEJgLGg== 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:(13230022)(4636009)(366004)(39860400002)(396003)(376002)(136003)(346002)(451199015)(66899015)(83380400001)(53546011)(6916009)(316002)(5660300002)(8936002)(38070700005)(41300700001)(2906002)(55016003)(30864003)(52536014)(76116006)(66946007)(66556008)(64756008)(66476007)(8676002)(66446008)(33656002)(4326008)(122000001)(54906003)(186003)(9686003)(86362001)(26005)(7696005)(6506007)(478600001)(71200400001)(38100700002);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: AS8PR08MB7943 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: VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 7c9ba15e-8d91-4d93-287c-08daa2e21ef9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zMusR6F4uhl81M2sjZZRXepGhdcSMqbb8VmRv2mL9Mo0ycuTooNtJSuSSVnjw7/x8fVa4BMdzaCkaXSOURHT77Jghi9gZqKSxXncPL9DB/dIsg5o+qmxY7M3P9Noeq7xwxH6UsKLHnKPAiGFxKshFTgzyDHFUzL8g++jkDn590/mGiXy0MOAL7aIng+9qWAwgzQrcC4204e7ITtumVXrtGTypQijd4583gsWIw8LcacMRXEmpBLvPTe/5fCkj1TIwAOP72ocVDBm2lstVWtQ2M5XxyLtvbO6fGTVZjXhY1csbpAgkH87FhfZOg6kRF2kQgfq1J1u2ydnXPkwSHh4xKVXzW371FeL/IHkJQlUVFPMQkIa3pQnzaVT4l9FpW8p4OrR41zSqpKWrkh88B5y1q+lJxFqbc/cvPK3Zn8zNeZL0NS1HGF0DPHYQN9Q/ulM3PaZQhAjbcS5A5ti+mTyw/1z9iv6Kv+oFGMyJxpFwlqyj45y0ehMiX2qfN93tCB6JFQ95p6KQODf8NZCk0Dh9MSMAWY+Wko+Tg/j/wds76JDHIp73rfgw/b8rh2SiAvxj62kH3m3UfjlY47/oZJTqaBFnhaetpGwH4+SJ68o3ap0kiyshjMCnIy32NJqOeGGGRnEYmrsoFnHVWdagKXJlX9S/RX0YnEmnwQfND1/ZZm2JZ04UvUll3abcWGsdkpHuiiQ1ayJc+GXBYn95sel9QnoxMYb6Q0M/s4fOeOemHXw2YgBSHJV0T9hty/BTXKgySLV0c0gzPClmUYxbanCAA== 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:(13230022)(4636009)(346002)(136003)(39860400002)(376002)(396003)(451199015)(46966006)(40470700004)(36840700001)(54906003)(33656002)(86362001)(66899015)(36860700001)(82740400003)(30864003)(336012)(186003)(83380400001)(81166007)(356005)(47076005)(53546011)(478600001)(9686003)(26005)(107886003)(70586007)(70206006)(8676002)(4326008)(316002)(7696005)(6506007)(8936002)(6862004)(52536014)(2906002)(41300700001)(5660300002)(82310400005)(40460700003)(40480700001)(55016003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2022 12:48:59.1774 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ff473e8c-f414-4c7e-71fb-08daa2e22500 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: VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB9677 X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,KAM_DMARC_NONE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,TXREP,UNPARSEABLE_RELAY autolearn=no 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 Biener > Sent: Friday, September 30, 2022 12:53 PM > To: Tamar Christina > Cc: Richard Sandiford ; Tamar Christina via > Gcc-patches ; nd ; Jeff Law > > Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional > branches, give hint if argument is a truth type to backend >=20 > On Fri, 30 Sep 2022, Tamar Christina wrote: >=20 > > > -----Original Message----- > > > From: Richard Biener > > > Sent: Friday, September 30, 2022 11:17 AM > > > To: Tamar Christina > > > Cc: Richard Sandiford ; Tamar Christina > > > via Gcc-patches ; nd ; Jeff > Law > > > > > > Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional > > > branches, give hint if argument is a truth type to backend > > > > > > On Fri, 30 Sep 2022, Tamar Christina wrote: > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Richard Sandiford > > > > > Sent: Friday, September 30, 2022 9:49 AM > > > > > To: Tamar Christina > > > > > Cc: Richard Biener ; Tamar Christina via > > > > > Gcc-patches ; nd ; Jeff > Law > > > > > > > > > > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of > > > > > conditional branches, give hint if argument is a truth type to > > > > > backend > > > > > > > > > > Tamar Christina writes: > > > > > >> -----Original Message----- > > > > > >> From: Richard Sandiford > > > > > >> Sent: Friday, September 30, 2022 9:29 AM > > > > > >> To: Tamar Christina > > > > > >> Cc: Richard Biener ; Tamar Christina via > > > > > >> Gcc-patches ; nd ; Jeff > > > Law > > > > > >> > > > > > >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of > > > > > >> conditional branches, give hint if argument is a truth type > > > > > >> to backend > > > > > >> > > > > > >> Tamar Christina writes: > > > > > >> >> -----Original Message----- > > > > > >> >> From: Gcc-patches > > > > >> >> bounces+tamar.christina=3Darm.com@gcc.gnu.org> On Behalf Of > > > > > Richard > > > > > >> >> Biener via Gcc-patches > > > > > >> >> Sent: Thursday, September 29, 2022 12:09 PM > > > > > >> >> To: Tamar Christina via Gcc-patches > > > > > >> >> > > > > > >> >> Cc: Richard Sandiford ; nd > > > > > > > > > > >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of > > > > > >> >> conditional branches, give hint if argument is a truth > > > > > >> >> type to backend > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > Am 29.09.2022 um 12:23 schrieb Tamar Christina via > > > > > >> >> > Gcc-patches > > > > > >> >> > > > > > >> >> patches@gcc.gnu.org>: > > > > > >> >> > > > > > > >> >> > > > > > > >> >> >> > > > > > >> >> >> -----Original Message----- > > > > > >> >> >> From: Richard Biener > > > > > >> >> >> Sent: Thursday, September 29, 2022 10:41 AM > > > > > >> >> >> To: Richard Sandiford > > > > > >> >> >> Cc: Jeff Law ; Tamar Christina > > > > > >> >> >> ; gcc-patches@gcc.gnu.org; nd > > > > > >> >> > > > > > >> >> >> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion > > > > > >> >> >> of conditional branches, give hint if argument is a > > > > > >> >> >> truth type to backend > > > > > >> >> >> > > > > > >> >> >>> On Thu, 29 Sep 2022, Richard Sandiford wrote: > > > > > >> >> >>> > > > > > >> >> >>> Jeff Law writes: > > > > > >> >> >>>> On 9/28/22 09:04, Richard Sandiford wrote: > > > > > >> >> >>>>> Tamar Christina writes: > > > > > >> >> >>>>>>> Maybe the target could use (subreg:SI (reg:BI > > > > > >> >> >>>>>>> ...)) as > > > > > argument. > > > > > >> >> Heh. > > > > > >> >> >>>>>> But then I'd still need to change the expansion > > > > > >> >> >>>>>> code. I suppose this could prevent the issue with > > > > > >> >> >>>>>> changes to code on > > > > > >> other targets. > > > > > >> >> >>>>>> > > > > > >> >> >>>>>>>>> We have undocumented addcc, negcc, etc. > > > > > >> >> >>>>>>>>> patterns, > > > > > should > > > > > >> we > > > > > >> >> >>>>>>>>> have aandcc > > > > > >> >> >>>>>> pattern for this indicating support for andcc + > > > > > >> >> >>>>>> jump as opposedto > > > > > >> >> >> cmpcc + jump? > > > > > >> >> >>>>>>>> This could work yeah. I didn't know these existed. > > > > > >> >> >>>>>>> Ah, so they are conditional add, not add setting > > > > > >> >> >>>>>>> CC, so andcc wouldn't be appropriate. > > > > > >> >> >>>>>>> So I'm not sure how we'd handle such situation - > > > > > >> >> >>>>>>> maybe looking at REG_DECL and recognizing a _Bool > > > > > >> >> >>>>>>> PARM_DECL is > > > > > OK? > > > > > >> >> >>>>>> I have a slight suspicion that Richard Sandiford > > > > > >> >> >>>>>> would likely reject this though.. > > > > > >> >> >>>>> Good guess :-P We shouldn't rely on something like > > > > > >> >> >>>>> that for > > > > > >> >> >> correctness. > > > > > >> >> >>>>> > > > > > >> >> >>>>> Would it help if we promoted the test-and-branch > > > > > >> >> >>>>> instructions to optabs, alongside cbranch? The jump > > > > > >> >> >>>>> expanders could then target it > > > > > >> >> >> directly. > > > > > >> >> >>>>> > > > > > >> >> >>>>> IMO that'd be a reasonable thing to do if it does hel= p. > > > > > >> >> >>>>> It's a relatively common operation, especially on > > > > > >> >> >>>>> CISCy > > > targets. > > > > > >> >> >>>> > > > > > >> >> >>>> But don't we represent these single bit tests using > > > > > >> >> >>>> zero_extract as the condition of the branch? I guess > > > > > >> >> >>>> if we can generate them directly rather than waiting > > > > > >> >> >>>> for combine to deduce that we're dealing with a > > > > > >> >> >>>> single bit test and constructing the zero_extract > > > > > >> >> >>>> form would be an improvement and might help aarch at > > > > > >> >> >>>> the same > > > > > >> time. > > > > > >> >> >>> > > > > > >> >> >>> Do you mean that the promote_mode stuff should use > > > > > >> >> >>> ext(z)v rather than zero_extend to promote a bool, wher= e > available? > > > > > >> >> >>> If so, I agree that might help. But it sounds like it > > > > > >> >> >>> would have downsides > > > > > >> too. > > > > > >> >> >>> Currently a bool memory can be zero-extended on the > > > > > >> >> >>> fly using a load, but if we used the zero_extract form > > > > > >> >> >>> instead, we'd have to extract the bit after the load. > > > > > >> >> >>> And (as an > > > > > >> >> >>> alternative) choosing different behaviour based on > > > > > >> >> >>> whether expand sees a REG or a MEM sounds like it > > > > > >> >> >>> could still cause problems, since REGs could be > > > > > >> >> >>> replaced by MEMs (or vice versa) > > > > > later in the RTL passes. > > > > > >> >> >>> > > > > > >> >> >>> ISTM that the original patch was inserting an extra > > > > > >> >> >>> operation in the branch expansion in order to target a > > > > > >> >> >>> specific > > > instruction. > > > > > >> >> >>> Targeting the instruction in expand seems good, but > > > > > >> >> >>> IMO we should do it directly, based on knowledge of > > > > > >> >> >>> whether the instruction actually > > > > > >> >> exists. > > > > > >> >> >> > > > > > >> >> >> Yes, I think a compare-and-branch pattern is the best fi= t > here. > > > > > >> >> >> Note on GIMPLE we'd rely on the fact this is a > > > > > >> >> >> BOOLEAN_TYPE (so even 8 bit precision bools only have 1 > > > > > >> >> >> and 0 as meaningful > > > values). > > > > > >> >> >> So the 'compare-' bit in compare-and-branch would be > > > > > >> >> >> interpreting a BOOLEAN_TYPE, not so much a general > compare. > > > > > >> >> > > > > > > >> >> > Oh, I was thinking of adding a constant argument > > > > > >> >> > representing the precision that is relevant for the > > > > > >> >> > compare in order to make this a bit more > > > > > >> >> general/future proof. > > > > > >> >> > > > > > > >> >> > Are you thinking I should instead just make the optab > > > > > >> >> > implicitly only work for 1-bit precision comparisons? > > > > > >> >> > > > > > >> >> What?s the optab you propose (cite also the documentation > part)? > > > > > >> > > > > > > >> > tbranchmode5 > > > > > >> > Conditional branch instruction combined with a bit test > instruction. > > > > > >> Operand 0 is a comparison operator. > > > > > >> > Operand 1 and Operand 2 are the first and second operands > > > > > >> > of the > > > > > >> comparison, respectively. > > > > > >> > Operand 3 is the number of low-order bits that are > > > > > >> > relevant for the > > > > > >> comparison. > > > > > >> > Operand 4 is the code_label to jump to. > > > > > >> > > > > > >> For the TB instructions (and for other similar instructions > > > > > >> that I've seen on other architectures) it would be more > > > > > >> useful to have a single-bit test, with operand 4 specifying th= e bit > position. > > > > > >> Arguably it might then be better to have separate eq and ne > > > > > >> optabs, to avoid the awkward doubling of the operands > > > > > >> (operand 1 contains > > > > > operands 2 and 3). > > > > > >> > > > > > >> I guess a more general way of achieving the same thing would > > > > > >> be to make operand 4 in the optab above a mask rather than a b= it > count. > > > > > >> But that might be overly general, if there are no known > > > > > >> architectures that have such an instruction. > > > > > > > > > > > > One of the reasons I wanted a range rather than a single bit > > > > > > is that I can the use this to generate cbz/cbnz early on as wel= l. > > > > > > > > > > We already have the opportunity to do that via cbranch4. > > > > > But at the moment aarch64.md always forces the separate > > > > > comparison instead. (Not sure why TBH. Does it enable more > > > > > ifcvt > > > > > opportunities?) > > > > > > > > > > If we change the body of cbranch4 to: > > > > > > > > > > if ((GET_CODE (operands[0]) !=3D EQ && GET_CODE (operands[0]) != =3D > NE) > > > > > || operands[2] !=3D const0_rtx) > > > > > { > > > > > operands[1] =3D aarch64_gen_compare_reg (GET_CODE > (operands[0]), > > > > > operands[1], operands[2]); > > > > > operands[2] =3D const0_rtx; > > > > > } > > > > > > > > > > then we generate the cbz/cbnz directly. > > > > > > > > > > > > > Ah ok, then if Richi agrees, bitpos it is then instead of bit count= . > > > > > > Somehow I understood that cbranch<>4 is already fully capable of the > > > optimization? > > > > > > On your earlier proposal I'd have commented that if it wouldn't make > > > sense to instead have a CCmode setter instead of an expander with a > branch label? > > > That would be a bit test, like {sign,zero}_extract compared against > > > zero which can then be combined with a branch? > > > > > > > I missed that part, that could work too. > > > > > Of course if the ISA is really bit-test-and-branch then cbranch<>4 > > > itself or a variant of it might be more useful. Maybe > > > cbranchbi4 would be "abused" for this? > > > > The instruction is an actual bit-test-and-branch with any arbitrary bit= pos. > > Yes we can abuse cbranchbi4 for this, but then it also means we can't e= .g. > > use this to optimize a < 0 where a is a signed value. With the new > > optab this would just be a bit-test-and-branch of the sign bit. > > > > But also I'm not entirely convinced that using `BImode` and assuming a > > single bit is safe here. What happens if I compile my source with -std= =3Dc89? > > > > So I personally think the new optab makes more sense here. The CC sette= r > would work too. > > > > I guess my question is, between you folks, which approach would you > > like. It seems that Richi You'd like a CC setter. Richard do you have a > preference of one over the other? >=20 > My order of preference is >=20 > a) an existing pattern, if possible > b) something usable by N > 1 targets we know of, even if it requires some > combine magic > c) something that fits the actual ISA > > For b), x86 has BEXTR which performs a zero_extract from reg/mem and sets > ZF when the result is zero. For a branch on sign bit there's easier ways= , so it's > probably not very useful for general compare and branch optimization and = if > (a & 0x30) is probably handled by combine(?). Agreed, I was more giving an example of other uses. But ok. > It also seems that if (a & 1) is handled for aarch64 already and it's jus= t a lack of > an optab that allows RTL expansion to expand if (bool) as if (bool & 1)? Yes this was what I was originally after. Your original suggestion was to = abuse BImode and cbranch for this. That could work, but I worry about introducing BImod= e in the RTL, as I don't think we currently use it at all and wonder about new missed opt= imizations. Richard Sandiford, would this be OK with you? I also don't want to emit an = extract here as I think that's gonna have a bigger effect on other targets than & 1 did. I would rather have something I can explicitly check for target support for= . I also wonder if just a target hook asking the target how to expand a given tree Boolean argument w= ould work. Tamar >=20 > Richard. >=20 > > Tamar > > > > > > > > > Tamar > > > > > > > > > > > > > Thanks, > > > > > Richard > > > > > > > > > > > > > > > > This would mean we could use my earlier patch that tried to > > > > > > drop the QI/HI promotions without needing the any_extend > > > > > > additional pass if we wanted to. > > > > > > > > > > > > We'd also no longer need to rely on seeing a paradoxical > > > > > > subreg for a > > > tst. > > > > > > > > > > > > Tamar. > > > > > > > > > > > >> > > > > > >> Thanks, > > > > > >> Richard > > > > > >> > > > > > >> > Specifically this representation would allow us to emit all > > > > > >> > our different conditional branching instructions without > > > > > >> > needing to rely on combine. We have some cases that happen > > > > > >> > during optimization that sometimes prevent the optimal > > > > > >> > sequence from being generated. This > > > > > >> would also solve that as we would expand to what we want to > > > > > >> start > > > with. > > > > > >> > > > > > > >> > Tamar. > > > > > >> > > > > > > >> >> > > > > > >> >> > > > > > > >> >> > Thanks, > > > > > >> >> > Tamar > > > > > >> >> > > > > > > >> >> >> > > > > > >> >> >> Richard. > > > > > > > > > > -- > > > Richard Biener > > > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 > > > Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, > > > Boudien Moerman; HRB 36809 (AG Nuernberg) > > >=20 > -- > Richard Biener > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 > Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, > Boudien Moerman; HRB 36809 (AG Nuernberg)