From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70081.outbound.protection.outlook.com [40.107.7.81]) by sourceware.org (Postfix) with ESMTPS id 4DB9C3858D32 for ; Mon, 26 Sep 2022 11:47:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DB9C3858D32 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=lV5jfm7x1OUm7ogj5vpHk5TMnooGYxgfdhT3ZJtzMeSfDTyqYEbs6EzW8TtTAvPbvPFYUKCkOYTyUWt461D68z5c86IwEL2zWPhDN2fXfH9Hv0AanNIIrHFdMa1WUiTVvyzxr72ZWUkuxKVRriIl9bi+ZTSi1l/qfAPz9rTZBi1s5ntkQNyd6Gew0UC0MGs2jySZR7EHHf4RS4GAqUdg0gl5RbyncHgCdKcZ+TBz61nbTGFQSSD/RAatsevhAiL9ziJgzLoUOqemeyvyTgQPFrBmf9cNSh/k+HgD7U7prOdHPRHtPOQsFdVr8hwO1/KoItd5ScgGiZnTTYrThcCLPQ== 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=1bZkcSCKX8YqiNXSCHNw4vHjXGfBUfMdMkhvnb1ZaMM=; b=IxZ1V6ye92oysFDfYL5fSc9R7MWCivs9ID3yDAnoKkPZhPZe5frO8XfzGzDSpYIVsWOwBO+TOlLQqyHKokR8oTtdCowTNlG4AolI7cXWJda4RCdsJES4kyzgmuOVAcdrq4yuqWt5MxWxvBUfLV3JaiuqXdD9Ru6qkUxqmMRzcfhAn3Uec9GeTH8MUr42n08uMb2YJELjXFnFAt7ijnnijUUwljo/2UTm0G4pfia4vEJn3luPWGybOEFgC7mUTxHaC9wdk8193PcT1e+2LW1qN6ceUQKu3i5crOtHFoHu1Z3+Rw1yylL8ppLhlxft2tpMny0KgOS0iwbKAe/pPKxgnA== 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=1bZkcSCKX8YqiNXSCHNw4vHjXGfBUfMdMkhvnb1ZaMM=; b=Nlgb8PyMjP54EKHSVw3yRbsyh1njOgcXzfzDWwIiwW2drQexVE2smYEtnWv3587qzFUy/3dXGg4to3c/oJ4tgrTBnFY4VkgnT3KVYPDFGQw2HMPZOHfy8y7zt4x6jyEfZBYmn1d/u746BgnIf3xkDPJk5Rq2RR8BgIIdHojjuWw= Received: from AM0PR10CA0058.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:150::38) by AS8PR08MB7989.eurprd08.prod.outlook.com (2603:10a6:20b:541::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.25; Mon, 26 Sep 2022 11:47:03 +0000 Received: from VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:150:cafe::74) by AM0PR10CA0058.outlook.office365.com (2603:10a6:20b:150::38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.19 via Frontend Transport; Mon, 26 Sep 2022 11:47:03 +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 VE1EUR03FT045.mail.protection.outlook.com (10.152.19.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14 via Frontend Transport; Mon, 26 Sep 2022 11:47:02 +0000 Received: ("Tessian outbound 3c27ae03f5ec:v124"); Mon, 26 Sep 2022 11:47:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: ce546a922e6613d7 X-CR-MTA-TID: 64aa7808 Received: from 122cf11fd080.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2ADB3591-F8EE-4D28-8B73-7CD65EF7386E.1; Mon, 26 Sep 2022 11:46:56 +0000 Received: from EUR02-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 122cf11fd080.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 26 Sep 2022 11:46:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAQ+aFaXeUqgADQXepBncoVR7pVafhqdAsac+GVQ4zxsVnsSNlC3ZgaAEGzsRFiUSHuEGhSly7CRrcMEfMbkbjP6tioCCNVMPqaWfda86ZJYtn6oDoOggz/W8/kxks8rjyDnjxwhYOUn2i+bvw4VjrGbmsMPChWP/2GJE+JfpBW7xXFm4y3gpobtzGuGyh9DzO5303GGdiO8Z4woIdlavVRqARxYMKaU3pAEmG3ohJXD+wrJp9AP384COMYkI21TG87xcuEmCnrWc0JjbnEnz3KVKgl1XJdQAoX6K1dCiVLk8VFxdyhVGF3dl544SrU+g4670aL9x2CYhmJ9ehH+AA== 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=1bZkcSCKX8YqiNXSCHNw4vHjXGfBUfMdMkhvnb1ZaMM=; b=fhukV+JYmQmy2idN0Lf3dd2R83FCAC0vsIq+128Gn794DKMXo3enVVjzjhlAsLvemy5A0yuNdM2mWOPVSHtnhAuZTn7eFlRLiQNS2iYvlGUw9I7CdujdX9jf/bIY4gLmrM85LkXi6gi6jMuOZfZv7BSetgAYYvqh3VYgsP9XSw//lIroDjZ+sZ7myxTIaiFj4irhgIGy1XWfDW/HdL6Xl2AphsTg1uBPQNjZM6GSGtzldp38twY1nwJ6qMpvsFswM7vsIvDN2t6/x2RhBTxf4T94WXcUktkGyStmkNCk2IhKQ8DcPPmLx3hSymbLvvqzZEK49kn2wftORQDEQSTlHw== 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=1bZkcSCKX8YqiNXSCHNw4vHjXGfBUfMdMkhvnb1ZaMM=; b=Nlgb8PyMjP54EKHSVw3yRbsyh1njOgcXzfzDWwIiwW2drQexVE2smYEtnWv3587qzFUy/3dXGg4to3c/oJ4tgrTBnFY4VkgnT3KVYPDFGQw2HMPZOHfy8y7zt4x6jyEfZBYmn1d/u746BgnIf3xkDPJk5Rq2RR8BgIIdHojjuWw= Received: from VI1PR08MB5325.eurprd08.prod.outlook.com (2603:10a6:803:13e::17) by PA4PR08MB6224.eurprd08.prod.outlook.com (2603:10a6:102:e7::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.25; Mon, 26 Sep 2022 11:46:44 +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.5654.022; Mon, 26 Sep 2022 11:46:43 +0000 From: Tamar Christina To: Richard Biener CC: "gcc-patches@gcc.gnu.org" , nd , "jeffreyalaw@gmail.com" , Richard Sandiford 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/QMK3xiPyAgAAF5FCAAAoggIAAAUoh Date: Mon, 26 Sep 2022 11:46:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: VI1PR08MB5325:EE_|PA4PR08MB6224:EE_|VE1EUR03FT045:EE_|AS8PR08MB7989:EE_ X-MS-Office365-Filtering-Correlation-Id: fa58e6bc-4942-4f56-90b8-08da9fb4d425 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: 5JXc0U3NNQe3ui46c1Nx0E9PwgtErPsw/5MqkXOqBFAA/wvWC57JB7DpnQxpqBABk8vswmeFrgZtxQgtKsqCnOvqg3IbS8BseGCbbBEH9CRPNe0ySvVZ32VdvDfhbzq7Ncg6jc6r51YOGLQu0DvOkPXQ2ZXdLOACBKnHDuzWn6JoZw9k5Kl0jomq4M8KGoTh/YwySlHzB8KUevq4ybRyW4ecKlK/yj/sq8yLrloBGFIUp5r+1h//nWUeId9wt/R3ScrZ75oho8tpELVnvEF2DQ2cCpwq20MgSEDkP8ugwnsWbl/9LgqZ2lm70jDtnQsX8GfsAUBHLm7Oq+IccWemMDmRcHUECkxXNDp+k+1dfrVqdJpG8tuirV6EMTzIEkJQ4ZD+TLKTRqHo1IZQuMH5Qk3hWbpiUilVFAEAU1BhFG0Dxv7HTviUw/NQCqgf1FIZUnHy+YAZbqpiEhZMi+CEhYxJCTIVnnO62ayaPjCZeu2/RvBBbx2JJlAsPLlHPaVzRAlyUv6smpBVCqI4wy+FoCwmcBoaTrEed4bay8gY5HpPIvwUcf+gEMS2KdB0BK7yZ78iBeDcxYecL3dqiqGCrOCJenguoAMJKwrUiOC4uvo9zVotDSg2rv+YYiHidihnDqp4dO+FlccAvsv7uRFbCPS57zl5MCUH1ejbdMOgZyoAYXfwgyr7tkjTrGM5JIQFEN88bj7aDTUpZqpG+ja/01KBTE21cGWcyB+wUePEkx0mf3YcIGD6dUoH1kdp7nQsvlLrxTcqs1Gzhiam3vnZUWujkAYm64bxCWUn/W0siPY= 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)(376002)(396003)(346002)(39860400002)(136003)(366004)(451199015)(5660300002)(21615005)(9686003)(7696005)(52536014)(26005)(6506007)(8936002)(53546011)(41300700001)(33656002)(83380400001)(122000001)(186003)(38070700005)(2906002)(166002)(38100700002)(55016003)(6916009)(54906003)(66899012)(76116006)(91956017)(4326008)(71200400001)(66946007)(66446008)(64756008)(66476007)(86362001)(316002)(8676002)(478600001)(966005)(66556008);DIR:OUT;SFP:1101; Content-Type: multipart/alternative; boundary="_000_VI1PR08MB5325E86B1125E7E72F96358AFF529VI1PR08MB5325eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA4PR08MB6224 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: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 3d409d44-76f8-46b2-533d-08da9fb4c88a X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FJvnocFQmJPp41A6zRqu3PeVVRlG2h77I6refD2Dz2iUYov2bWKNHRJ4mWe3bEW9HMwoRXhwHXJLJfxfxFpLKYIExqAVppc2aA461TbW6BhNzmaGAYDG6j4OCxCggPvBuva2v72ybf2xA+CBSGQ/9J9JtpigrurNPAeD+LGCV/aOxb/cAZMhStZ2dvp5D3HOtDYeYyf8la2GfAFeAL5cLttsZY9Zn3X2mQGAzuSXebF9YDRHZ3n7s+9yNYL+xQKSPlLZ7xx/m3Hn0xbLwIRTN7xGc0scaiBFd0kpXxhf0pvVLY1GL6O9EozqNDhUVJY0MqOi8eL3hm07+0b7N/c5sRQrL9oUuSsceUxjg/6GrIiS0EgaEUxmW+Wl9FQhs/8WUxS3esmfm+51W2n2vVmHIfYh6nFYP2Aeop84/cFHLV1Sy0G06aCtlFV5khE40qoW737xTUWfWLly/O4O9pkZ6glwqQBl6ljxa5oCtehsvXopI7rbDb1gjc4BJbE+oQA6HAcbn2NDO6RR7AUY0E1SmUFLAncui9CpuIbYV3wtkdJk8cb6OU2A2+pdlbdkZa1guRkpP/DrT2v9Wfv/k1SW/uZ4YvXpa+wi2SsS+IZT/ie07uf1PFUfPC+j6GMiu9vk68kRKT+Zh9KKrBk6VVhKJqdNhN2kcZJExK2GYe94hqnD1NgJ9OZtwF2LLnz9vFSgim05ZeC7ROtbpnG3qeS8V3SJVK+L/k7vAeRUxnfO27ySRPqSSc/QkXzGuxU6Mdi10LH/1Qn6W1l7vPDSfeJ/kaV/f/bFH2xqiiew0/tHYvc= 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)(376002)(346002)(396003)(39860400002)(136003)(451199015)(36840700001)(40470700004)(46966006)(82310400005)(356005)(166002)(82740400003)(478600001)(81166007)(966005)(316002)(54906003)(186003)(2906002)(4326008)(70206006)(8676002)(41300700001)(70586007)(26005)(9686003)(86362001)(66899012)(21615005)(5660300002)(55016003)(40480700001)(30864003)(47076005)(83380400001)(33656002)(336012)(6506007)(7696005)(52536014)(53546011)(36860700001)(6862004)(8936002)(40460700003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Sep 2022 11:47:02.7101 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fa58e6bc-4942-4f56-90b8-08da9fb4d425 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: VE1EUR03FT045.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB7989 X-Spam-Status: No, score=-12.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FORGED_SPF_HELO,GIT_PATCH_0,HTML_MESSAGE,KAM_DMARC_NONE,KAM_LOTSOFHASH,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: --_000_VI1PR08MB5325E86B1125E7E72F96358AFF529VI1PR08MB5325eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > 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 aand= cc 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 t= hough.. The additional AND seemed less hacky as it's just communicating ran= ge. I still need to also figure out which representation of bool is being used,= because only the 0-1 variant works. Is there a way to check that? Thanks, Tamar. ________________________________ From: Richard Biener Sent: Monday, September 26, 2022 12:32 PM To: Tamar Christina Cc: gcc-patches@gcc.gnu.org ; nd ; jef= freyalaw@gmail.com ; Richard Sandiford Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional branch= es, give hint if argument is a truth type to backend On Mon, 26 Sep 2022, Tamar Christina wrote: > > > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is= quite common. > > > How does this help a target? > > So the idea is to communicate that only the bottom bit of the value is re= levant and not the entire value itself. > > > Why does RTL nonzerop bits not recover thisinformation and the desired = optimization done later during combinefor example? > > I'm not sure it works here. We (AArch64) don't have QImode integer regist= ers, so our apcs says that the top bits of the 32-bit registers it's passed= in are undefined. > > We have to zero extend the value first if we really want it as an 8-bit v= alue. So the problem is if you e.g. Pass a boolean as an argument of a func= tion I don't think nonzero bits will return anything useful. > > > Why's a SImode compare not OK if there's no QImode compare? > > The mode then becomes irrelevant because we're telling the backend that o= nly a single bit matters. And we have instructions to test and branch on th= e value of a single bit. See https://gcc.gnu.org/pipermail/gcc-patches/2022= -September/602090.html for the testcases Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh. > > 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? Richard. > > So - what's the target and what's a testcase? > > See https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602090.html = :) > > Thanks, > Tamar > > ________________________________ > From: Richard Biener > Sent: Monday, September 26, 2022 11:35 AM > To: Tamar Christina > Cc: gcc-patches@gcc.gnu.org ; nd ; j= effreyalaw@gmail.com ; Richard Sandiford > Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional bran= ches, give hint if argument is a truth type to backend > > On Fri, 23 Sep 2022, Tamar Christina wrote: > > > Hi All, > > > > This is an RFC to figure out how to deal with targets that don't have n= ative > > comparisons against QImode values. > > > > Booleans, at least in C99 and higher are 0-1 valued. This means that w= e only > > really need to test a single bit. However in RTL we no longer have this > > information available and just have an SImode value (due to the promoti= on of > > QImode to SImode). > > > > This RFC fixes it by emitting an explicit & 1 during the expansion of t= he > > conditional branch. > > > > However it's unlikely that we want to do this unconditionally. Most ta= rgets > > I've tested seem to have harmless code changes, like x86 changes from t= estb to > > andl, $1. > > > > So I have two questions: > > > > 1. Should I limit this behind a target macro? Or should I just leave it= for all > > targets and deal with the fallout. > > 2. How can I tell whether the C99 0-1 values bools are being used or th= e older > > 0, non-0 variant? > > > > Bootstrapped Regtested on aarch64-none-linux-gnu and no issues. > > However there are some benign codegen changes on x86, testb changed to = andl $1. > > > > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is q= uite common. > > How does this help a target? Why does RTL nonzerop bits not recover this > information and the desired optimization done later during combine > for example? Why's a SImode compare not OK if there's no QImode compare? > We have undocumented addcc, negcc, etc. patterns, should we have a > andcc pattern for this indicating support for andcc + jump as opposed > to cmpcc + jump? > > So - what's the target and what's a testcase? > > Thanks, > Richard. > > > Thanks, > > Tamar > > > > gcc/ChangeLog: > > > > * tree.h (tree_zero_one_valued_p): New. > > * dojump.cc (do_jump): Add & 1 if truth type. > > > > --- inline copy of patch -- > > diff --git a/gcc/dojump.cc b/gcc/dojump.cc > > index 2af0cd1aca3b6af13d5d8799094ee93f18022296..8eaf1be49cd12298e61c694= 6ae79ca9de6197864 100644 > > --- a/gcc/dojump.cc > > +++ b/gcc/dojump.cc > > @@ -605,7 +605,17 @@ do_jump (tree exp, rtx_code_label *if_false_label, > > /* Fall through and generate the normal code. */ > > default: > > normal: > > - temp =3D expand_normal (exp); > > + tree cmp =3D exp; > > + /* If the expression is a truth type then explicitly generate an= & 1 > > + to indicate to the target that it's a zero-one values type. This > > + allows the target to further optimize the comparison should it > > + choose to. */ > > + if (tree_zero_one_valued_p (exp)) > > + { > > + type =3D TREE_TYPE (exp); > > + cmp =3D build2 (BIT_AND_EXPR, type, exp, build_int_cstu (type, = 1)); > > + } > > + temp =3D expand_normal (cmp); > > do_pending_stack_adjust (); > > /* The RTL optimizers prefer comparisons against pseudos. */ > > if (GET_CODE (temp) =3D=3D SUBREG) > > diff --git a/gcc/tree.h b/gcc/tree.h > > index 8f8a9660c9e0605eb516de194640b8c1b531b798..be3d2dee82f692e81082cf2= 1c878c10f9fe9e1f1 100644 > > --- a/gcc/tree.h > > +++ b/gcc/tree.h > > @@ -4690,6 +4690,7 @@ extern tree signed_or_unsigned_type_for (int, tre= e); > > extern tree signed_type_for (tree); > > extern tree unsigned_type_for (tree); > > extern bool is_truth_type_for (tree, tree); > > +extern bool tree_zero_one_valued_p (tree); > > extern tree truth_type_for (tree); > > extern tree build_pointer_type_for_mode (tree, machine_mode, bool); > > extern tree build_pointer_type (tree); > > > > > > > > > > > > -- > 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) > -- 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) --_000_VI1PR08MB5325E86B1125E7E72F96358AFF529VI1PR08MB5325eurp_--