From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-DB5-obe.outbound.protection.outlook.com (mail-db5eur02on2065.outbound.protection.outlook.com [40.107.249.65]) by sourceware.org (Postfix) with ESMTPS id E7D27385415C for ; Fri, 30 Sep 2022 11:11:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7D27385415C 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=j6UMu0P2Z3/I96QtTiPmNbLtrbn6tvvQN44IkFqr72av5ZaRBzu7CNYyrYJ9465lSVZ7tolL3jSWvBiq2XJsKawCO+VwOSau5nBt+DliLvwMbZ8ZYUX/CmMeBDDstF3i+9K/aTqGig0vEytOPydWrm4i6Z+9z6rB+Y36AQ6cUVPMG6hyScu7srMCjK9jGlJjk1rixVvOKKdNekCkFSkTzaabRZWs0wLCBlRV9L7se3Bf+ofIye9f4A/s7PLMXnDb93QaqDVIxtN8kJAUBUCoQbHcuEK3JySeFWkDN+kQK7XdALpG6GncaCOhJXgB5EPM8T/xII/Xj1N44dNTIaCAoQ== 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=HT9PvcZ4CW/wZ2zNTd4N5bK3F1PAryEbZ10Wj2U5lxc=; b=YQRLVsEKvkinoTE8K1WNzeHKyq72WBv+rTg/3NyJvbmGiQqZvlJ7dpNCMZDtrQeorW9N+wH8VzjraxyCyiuZIdV4P/JpPrVWI/4K2OSDtEFzUpTbv4Q9Yh+E6klZ/W9k+6FN3GsLyeDfz6mNt+UC2nPawyJQscnmJRmbUvN2H6OoQGcKjxo32/41P8jZSsefdxHmUADqOXAsBjaWj2giWGfSPTvPtTYw6uwn66xi3w1VG+fHWiGzqAybICPbSvfFh+NdAv6YDEJMMKEK9xz4QJRgAzgKOWEzhoHpq8m30wvj5HyEW4MoRmpSYMs4Bsz8Sf5fxx8Rj+mP2TRdLYaQSQ== 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=HT9PvcZ4CW/wZ2zNTd4N5bK3F1PAryEbZ10Wj2U5lxc=; b=rihQ9tJVnKl+rOVx5pu7RCkT8/TfITv2ztK82R9sThcyfOUanN9OIJfKuODncSeKdjY0PswB7iA+EU8IaFncRVIfMcoDjMUom7Wlq+l18hxNB0yInNeqmWYfK5BZwRvhcYSDJtwrNUm7Dc8I5uic054+hH13PX9tq+Sbi3W83kE= Received: from AM6PR05CA0030.eurprd05.prod.outlook.com (2603:10a6:20b:2e::43) by AS4PR08MB8190.eurprd08.prod.outlook.com (2603:10a6:20b:58d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.19; Fri, 30 Sep 2022 11:11:49 +0000 Received: from AM7EUR03FT020.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:2e:cafe::f2) by AM6PR05CA0030.outlook.office365.com (2603:10a6:20b:2e::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.23 via Frontend Transport; Fri, 30 Sep 2022 11:11:49 +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 AM7EUR03FT020.mail.protection.outlook.com (100.127.140.196) 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 11:11:49 +0000 Received: ("Tessian outbound 937eed45f6ed:v128"); Fri, 30 Sep 2022 11:11:49 +0000 X-CR-MTA-TID: 64aa7808 Received: from 134460b7d90f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C67F9028-C0F5-4106-90B9-3FCF097A5935.1; Fri, 30 Sep 2022 11:11:41 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 134460b7d90f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 30 Sep 2022 11:11:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gW/YEpL8dUrpVKLJ48U0YakBUavG1hzsZgEVaA4eJJgc8xGY0XcRi3VMe+jSSgEaX805pgkfry4yF0pmz/BxbkH83pvbO8pjG2GvN1Fl0GS3DAZQ857gl4kg8AaI24EIlWmKX5ctpx2N3ZJrZRn05sqHzv0vNdTRBpndDu0gxcFAC6vwdJeyndOqTbIxZJS2RquZJdLk5HGig3UaAgTJSmRlnd+GhW+bmrn7f6Pjt3OCFw8hWTSFp0RRW8rzMQdRXL6W++9ZCrTEgpJrsrHWuEyQoGyt73SvZ2tdDwS7pVpRp/A5i+TkTXiR/a1r4oGU1F00M9RHkjsIUxvzX65YqQ== 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=HT9PvcZ4CW/wZ2zNTd4N5bK3F1PAryEbZ10Wj2U5lxc=; b=IWOoeNydUDr5CTEaQOtcDjZvKqzJp8GE3mAOOCdUBI38pA2NlxJQywVRtjZUqcOcdaUVOIWuEV2JsprYO5YtA1aGnFfeJZmYfxqDC0LUJ9r+wietmlChTWWhfFqHKCq1groY7l155DSxWbScyHKpti7ECa85mTP1MUqRzkA+uwb6nmUVujXRc/rQGSubDaPmxm4PTqwz0o6esc0x2eUNc7ldOI8VNnxRgZXFCP3LGhwX6VzdJ4CwDVyc3oWDinygrzdib/Om3A5tgeN8zT0CczyalB5sUKM8dsnd2aBY8I9pBWAdp/eGTla62X69Fi2GWUevsoCqO1UnYtmf7gqU7Q== 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=HT9PvcZ4CW/wZ2zNTd4N5bK3F1PAryEbZ10Wj2U5lxc=; b=rihQ9tJVnKl+rOVx5pu7RCkT8/TfITv2ztK82R9sThcyfOUanN9OIJfKuODncSeKdjY0PswB7iA+EU8IaFncRVIfMcoDjMUom7Wlq+l18hxNB0yInNeqmWYfK5BZwRvhcYSDJtwrNUm7Dc8I5uic054+hH13PX9tq+Sbi3W83kE= Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by GV1PR08MB7915.eurprd08.prod.outlook.com (2603:10a6:150:8d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5676.17; Fri, 30 Sep 2022 11:11:36 +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 11:11:35 +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/QMK3xiPyAgAAF5FCAAAoggIAAAUohgANeuPmAACaxAIABECd3gAAA3gCAAArogIAADeOAgAFOFmCAABdsfYAAAasggAAD8PyAAAcNMIAAEXKAgAALrXA= Date: Fri, 30 Sep 2022 11:11:35 +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: 9DC9E83AE3048A43945E7C7360CA2830.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_|GV1PR08MB7915:EE_|AM7EUR03FT020:EE_|AS4PR08MB8190:EE_ X-MS-Office365-Filtering-Correlation-Id: d09ba209-17d0-4166-1b22-08daa2d49231 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: ioBsEw0nQFRpQGcjFbJV8ibI9/casYu+tzePvKM1hlleXNsiG8TBsAFLZh+C4y6bj8Ah+vdRrDlYFwBIDEBNgZ5Lm92ZDTuIsoSAR48GV3QwWH+ZDa15Pt3hu7L0sWOoQWub9x1k+DG5qEaybb3rQ6ZmZuWgV0az0PpZb5yfftTyHWzudYOX46PkBZPsmh0vEbsS10arlea4J5hJQ7wmdYmzwMfZSpPCpela5i+O0GnOUAtPzCOWllwjBqiPX5ho7b26sK7Nmjk0Wxzde35KScZHT5ZLBCEDRq0SoEVJ+4aD+GMw0rW9vockzsdFg+aVaoPppFz5W3DoziQ4uvvSQzdBN3cD9NMREZ3M/Kba3+CGLVxQ8FNe1ottzUteCZR2YyVe7cPqlPXtLwiqHOUcBGCveZohhc6Q127sNJO2pIc9QfY9rPM7qKc1iW2o9x6E6YDtMj1BfJmnLmjdTX2fhYThTMzumTm8VVdU8ACgeZi71JvoiiHaVmbFX4xdD2Fs5A2s7m4mOMXOPuJ+o8OdRQonRgDH2P+RNzDPlt+wGfNt/Cq22ob3DwPZn2LYEyiyh4NFLHdyIzltkZ1Suab/6v+0a/6oY8Px59us5Nhv/lnz5YCdf8UfYt4m8rfuzukx4zyzFiQIvXKOGb+5TvcyKvnywEIhI2f98NhsN8QQXfQbpGinVcxHtSfPXTIcYl+XslCCLBOrf55qGLO/KZgNg443g+m42c+AJoeBOjn6Zt7iDdazHamWJcP4lhKlJsJx04XGH5Bup7aFIHoD1892uomefWPjd8tYlVnjZIE+RlZ/xKcZHlFL0PyQgMtMxeB6 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)(136003)(396003)(366004)(39860400002)(376002)(346002)(451199015)(83380400001)(38100700002)(26005)(54906003)(9686003)(316002)(6916009)(33656002)(2906002)(38070700005)(122000001)(52536014)(186003)(5660300002)(30864003)(41300700001)(86362001)(66476007)(55016003)(66446008)(76116006)(64756008)(4326008)(8676002)(66946007)(71200400001)(478600001)(66556008)(66899015)(6506007)(7696005)(8936002)(53546011);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: GV1PR08MB7915 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: AM7EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: dd5ba37b-4051-47cf-6aae-08daa2d4899b X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZJKXvexBFTf9nMdoo5egzuOovN0vElZSlbyyxJmFSLd3n1G22xdQxaRa1GbjOipnEAA2lA16xTwDS2v+0i+oJin3RNy9HOGoRqeNhTHZk7SS9VVrpDnDhd/d8oudQH4a+OBIkZP3enJFATaV8k4CuZVV0oWctlfpGlYYcvEo0OJ+D12knll+boSFGjhb8usEm4GaZjZpH8uzPqqz71EZ9MKFo2sMWxzosVW7Uqww9EIa+f2yE48ViNuyQxdYyBJrEcdnNnkIkfC2D1PrPsUvpySSXtzTVTLAulJqRyk4hYED0urnRu8za1xEsRmJaLVjXoVBpU2ElruVaCZrqpaFZO5c17U4+C8tOh0OLwftKKityxshJl5iyaSbrlDA59ycu+EDQkTQoMqRa20GpS7BldNVLq+7zaxgCjeGL8GOfESMYog/B2QVQtEzyYgS+WrwbZQa17tY2kOOvdgkvIPdyBBRLyKflAmNebF+qcaCw21Nrxtg+nu0oeLIppJQ7/7grtocJDBr79x094eIZsWVl3eMmtvta77PQZi2v6vxejxohK+yMRRi0dNVYvnnC/6ZbYjcLy2lBb8GSlM6sIU8MqUTKnAoonvrOudLye/8GJW6bUaY90EK9qc20udNa4gl0RGvGRAGFUqtMTu8C2pED2bWFgKk0Y0PoYpPp0rc35ye5lcV3acWMeenccPSpMA4S/V2Pw4n3KZab5r9KguoDWdukHMIjNtEh66oMLd9b66vaU/9ONYVIVbXxYYyBtS891vF/noMgBkDHXa2M8XMLg== 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)(39860400002)(396003)(376002)(136003)(451199015)(36840700001)(40470700004)(46966006)(356005)(82740400003)(4326008)(478600001)(33656002)(40460700003)(9686003)(6506007)(86362001)(82310400005)(26005)(81166007)(53546011)(8676002)(70586007)(70206006)(52536014)(41300700001)(8936002)(6862004)(55016003)(7696005)(316002)(54906003)(36860700001)(107886003)(186003)(40480700001)(30864003)(83380400001)(5660300002)(47076005)(2906002)(66899015)(336012);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2022 11:11:49.5023 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d09ba209-17d0-4166-1b22-08daa2d49231 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: AM7EUR03FT020.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB8190 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 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 >=20 > On Fri, 30 Sep 2022, Tamar Christina wrote: >=20 > > > > > > > -----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 help. > > > >> >> >>>>> 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, where 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 spec= ific > 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 fit he= re. > > > >> >> >> 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 meaningf= ul > 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 instru= ction. > > > >> 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 the 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 bit coun= t. > > > >> 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 well. > > > > > > 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. >=20 > Somehow I understood that cbranch<>4 is already fully capable of the > optimization? >=20 > On your earlier proposal I'd have commented that if it wouldn't make sens= e > to instead have a CCmode setter instead of an expander with a branch labe= l? > 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 bitpos. 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 sing= le 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 setter wo= uld work too. I guess my question is, between you folks, which approach would you like. I= t seems that Richi You'd like a CC setter. Richard do you have a preference of one over the ot= her? Tamar >=20 > > 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. > > >=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)