From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2109.outbound.protection.outlook.com [40.107.94.109]) by sourceware.org (Postfix) with ESMTPS id B0DFB3858D39 for ; Wed, 2 Aug 2023 03:45:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0DFB3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=os.amperecomputing.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=os.amperecomputing.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RCoRprXQhGifqFCttlFXFqv3x+SsUfcPbuzch5PXhgnY/d+pDfCiybhGnrXlXfxL51QXFIZmFMQyq55qXGtCAD6wWH2Uyo+Q2AB6CRqglOAJGy7QUh/zgKv1xHmM4wB8XcfAnerSumr9mYjNhi/19yq6BPPo/Oc/+eT30WcKyl9B9xqTxBbQcQjpjMcSkk8Q3g1P5p3bDlKXdzfPDYGjaM3xe2054F6M4oWcPYTNQzf6tPxS7ryTiZPUv5FvNylCnRR7gXB2fy4B/MYYwTPupoyteVnWNOxH3omj8kfSXG+IQTbNnR3g7WsruvXhzb11X727SUmjH/Q7d0bGC0a5kg== 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=/B//lz0AQ6be/UNbYGQXiafuSrHrJ4iuzrk/2e6MB64=; b=ij2Sj9CHVcIybQyBJDVk8MPAV+2JZfQhGWs8MRXKc9zl/3qSKSOyAmfdlqSXHGxx7+C/vL3gKTT6dEy5JOL7zaJq9IkXYSPT+dNXbOxGQ5r/zd1S8eLQCc4DQFo7PybKk3WvxWGcrIwjvUaKnEIg1mjsZiMI37rr9ouvOVWfbrP3vST1NFn7irC6uZ+T6uXTjl2vrcwFZitMARxy5PdLlf9L8H1VfVZYpIq3WHSmgNS/lGfA/YegvxwLiR+jeDW6Bxp4uwbiMWAkk8yFKnoFMtpwqP77ldbmfLML553wag0St16gV9WTe+Kpm8xFHkvvocnGzdkVkspg8AlbrF1acw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=os.amperecomputing.com; dmarc=pass action=none header.from=os.amperecomputing.com; dkim=pass header.d=os.amperecomputing.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=os.amperecomputing.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/B//lz0AQ6be/UNbYGQXiafuSrHrJ4iuzrk/2e6MB64=; b=RRR1nRudq+VLMOJ0DfI95ET4zEdkpAyDTJx65c1M+8eg0gf5pQtWBwsN8ZAuVebQvahIxa1Uy/ATd1eniCiDplLhBvnG8d5VWCZbVv1wOJsg7OS8eN8i9dsWBfNzzaFX+t8xdmPSj9+dT7XXHlJ0tACckHnTE1GOxxLUjJRXL0g= Received: from SJ2PR01MB8635.prod.exchangelabs.com (2603:10b6:a03:57b::16) by SA1PR01MB8393.prod.exchangelabs.com (2603:10b6:806:383::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6631.45; Wed, 2 Aug 2023 03:45:50 +0000 Received: from SJ2PR01MB8635.prod.exchangelabs.com ([fe80::4c34:715d:c446:7fc5]) by SJ2PR01MB8635.prod.exchangelabs.com ([fe80::4c34:715d:c446:7fc5%5]) with mapi id 15.20.6631.043; Wed, 2 Aug 2023 03:45:49 +0000 From: Hao Liu OS To: Richard Sandiford CC: Richard Biener , "GCC-patches@gcc.gnu.org" Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by multiplying count [PR110625] Thread-Topic: [PATCH] AArch64: Do not increase the vect reduction latency by multiplying count [PR110625] Thread-Index: AQHZuflIfzSQE63nDUGU9bz2B+2yKq/Iyx9zgAFtZ+aAAAyoV4ABDpZUgABz54CAAAd444AAOh/TgAN2f3eAA7nMmIAAcKY/gAGZXh6AAS79PA== Date: Wed, 2 Aug 2023 03:45:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Enabled=True;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_SiteId=3bc2b170-fd94-476d-b0ce-4229bdc904a7;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_SetDate=2023-08-02T03:45:48.111Z;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Name=Confidential;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_ContentBits=0;MSIP_Label_5b82cb1d-c2e0-4643-920a-bbe7b2d7cc47_Method=Standard; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=os.amperecomputing.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ2PR01MB8635:EE_|SA1PR01MB8393:EE_ x-ms-office365-filtering-correlation-id: a601ce2a-bac2-474d-d33a-08db930af65e x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kxD55cIIxyRO3miggWvz/jNA5jq8qiTBNTkWr+qLSZmR5oFDz/5RuzSQnYmUV/a3T0DqJ03cUtan/52kQLr6yrTJfa4Lb+Kn/HtzRSTn/zAg52sFwTg/YFOTlZZ5CFla6eexLFDHxeFCO93b5Nr0TAgOZZxoPKe1YU+lTSo5uY6tJ9LGElOZIIiJcYrMnhsdQsJ9FcaYM00CXKP9iUEJzbKKJRtQ29Zjnt7Be38bSv/IyoM+//8SCG7lEg9zJY36YRerDvy7ufLIDe6EgRU0LkdWbaLFviesAS5IWnBJ/vgX9pOvxVPUaR9/cxFhQaVbDShR0ukOptUvZeJhChX+a7Z8Ga/yHXULorIP+WOwWHW2kGtRiMZIDlt3oGTKaISXqHfv9KRiInnNoXty8niY6YhKSV1KZ7s82c8hvGBYG+4oSqv8HbO2Vu2aLxBlWbV56/gVA4R456JVniIJJBRVkxV0wkcKutesr4Xl0zNVXbFxOrUtlV++Xsb0ZVfwnB3VrF3I/px3/EwCv5alOfR6vL4X6aPpuJe9sYC5vF+v6lDav8DzY54dQBKwmvLnmMBoOMGE4ckyfVSVYFRFEL7IVqx5P6THKNV4yl+EvedIDOA= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ2PR01MB8635.prod.exchangelabs.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(376002)(366004)(39850400004)(136003)(396003)(346002)(451199021)(55016003)(186003)(9686003)(316002)(86362001)(478600001)(122000001)(54906003)(38100700002)(76116006)(71200400001)(66946007)(66556008)(66476007)(91956017)(66446008)(33656002)(64756008)(7696005)(6916009)(4326008)(6506007)(53546011)(41300700001)(26005)(52536014)(8676002)(5660300002)(8936002)(84970400001)(2906002)(38070700005)(83380400001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?KUmy99Xoxpg9pYcbBDsJeW7epNnbeMfGp+0TnR38kWyLcbuP1ONl/l5dmCcr?= =?us-ascii?Q?EoOTcWqxSLRJC53NxiLqB7YC3jN79ANOC+AOvL5I3ipYQpAOpTqMLZJXeVf7?= =?us-ascii?Q?uPT4PWy5nklXwq7gd/knc5kGqDB/EZE7ckdopkEmmJh7/aSWXftDSi+nqki2?= =?us-ascii?Q?Dqoil41gjGepYBbzitxLuGTD2RGPmzcID+LHRiZrjt6HKBMXyjQ0DGK1DjaE?= =?us-ascii?Q?Ky6K/mjMDQ+Bwi8LGGfUh3Xoj0awSLXfP+884G6c0ay2TCbjaJp7ABdBjwKp?= =?us-ascii?Q?CP5lnIZjq2p4inB5FZSNiYdGbzSYvevyU8KIGz7O1zbVi5LVkRWtYK/1TmJZ?= =?us-ascii?Q?SBgg9g0GHXSgUZA5osdSMyRH8VX8ZqiHtBdKoidN7FZDeTvJrQAeLWcXZklu?= =?us-ascii?Q?OfHDh5iRTTYyN69gl5KlfQsSAXGSQTKLDruxonFrKBqFE909ko9xbXgXdQBM?= =?us-ascii?Q?JyoGKi1QnxNhqEqzzWjZYWvHZgf7Hp4+b+OLXLT5Miu7Mv0HZpNptwN/PM3t?= =?us-ascii?Q?qswxosaqrdSmqloQpNICraH8T1YUzYhFX5sLxdphyQfihDeZWYGI8Fk0AVpH?= =?us-ascii?Q?LT0Qpc+mYxDlEcKO4I6D2f3xRFVLgms0J5f3HW1izZmOWGdXUM5wyYB0fOQ2?= =?us-ascii?Q?TK/lkiOINLjmU5dO5OosD4Kn6Pylbco0/5HMC4Dy4G91F2gtLzXdYVJhjLlR?= =?us-ascii?Q?zWIEaclbm0iFc5kw+yM6/w86Ah9ugplgmj8Zo4N2nTGg3dDF76owD2VSOcCk?= =?us-ascii?Q?DTKss8Bo5g73rWdzodP7kQ7vxj1N92uQ00cveRtdVCiAsmNkLqeaDdhaM89v?= =?us-ascii?Q?3CuMmv+nOfXBE2Zr7ZgskHXBBLKdCfrodyeeddirG7L0kodTJ6RxdUSEgmlV?= =?us-ascii?Q?AuEcB5cvJRi/QOuEzNnsGDzZSMofn6LaCXN+7AlHLey73wcSefMv5fUME8ic?= =?us-ascii?Q?XRg4msNMRjNBWaybPjcfx0m0AdoJAPE9LtiPQafg0MZKclfdn70Bwx3VZMVh?= =?us-ascii?Q?SAe/9a6gOThfmjFKtmA0TOarzr/zSmv+C16JQBf98CUOtBLU8vVJX0GU2+fS?= =?us-ascii?Q?N1nT69GbgjdwISQObkYhu8mVlJo0WrXM1ig+Wg7SKcEBJlIHgTdfhR6hBXN4?= =?us-ascii?Q?RJn+Q8u82ztmO4VfzKflzDi+IFuhNIN8cRPG3Q7ulpY+Nuc5mKPV1kd/gxYN?= =?us-ascii?Q?DHLm6zXxxdETNSptKUZ1As86/RRBtau57kxb1iqNehVEOuIvgXgNTrafyrE/?= =?us-ascii?Q?cno+YusNysYDxCiD8+HF996GwEvMXpdFZabqQGhWEbFmqc06a4Y2xssuO6s+?= =?us-ascii?Q?IR7HQ1DzkOBbaIi+tdkH3/juvuSfL9j+RGYUFW6QKUhm18umZIvkJW8sFCoZ?= =?us-ascii?Q?AR1qT807mvZLAznvqOwshyQDyDU3wrT6NbYjuTZOdUdlskmWy/iJffEl3u4Y?= =?us-ascii?Q?xSG7orfRWZjrhYm7W6WJl9p5LbZG7qG3OeOfx/6XI1O99DHFIQqFk6Ojk3GH?= =?us-ascii?Q?OOu2E1BvlZk4j4L+Dhy0Yo2v+27+xFt4JYbUoIDDj1XxonYWw2RKAe+k3XeK?= =?us-ascii?Q?muIeyxTecSKfXH53e5j8uQvUGgLLIW+fSFaGyotP04CxSa7bLTZsHGRnAFVe?= =?us-ascii?Q?7w=3D=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: os.amperecomputing.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ2PR01MB8635.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: a601ce2a-bac2-474d-d33a-08db930af65e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2023 03:45:49.4849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3bc2b170-fd94-476d-b0ce-4229bdc904a7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Nxnr1AX8FHkBssQPkiSrCGx2W8bWSEKe2XNkvyL1Q7R/LSXr99gGf7Zv1UbHCHJfMYakbt21M7oYZVXBInFeHEaZPrLGXKO9/7rH1lLF2oMsGLPF3Dh/XXF9G1SHtoKJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR01MB8393 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,GIT_PATCH_0,KAM_ASCII_DIVIDERS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hi Richard, Update the patch with a simple case (see below case and comments). It show= s a live stmt may not have reduction def, which introduce the ICE. Is it OK for trunk? ---- Fix the assertion failure on empty reduction define in info_for_reduction. Even a stmt is live, it may still have empty reduction define. Check the reduction definition instead of live info before calling info_for_reduction= . gcc/ChangeLog: PR target/110625 * config/aarch64/aarch64.cc (aarch64_force_single_cycle): check STMT_VINFO_REDUC_DEF to avoid failures in info_for_reduction. gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr110625_3.c: New testcase. --- gcc/config/aarch64/aarch64.cc | 2 +- gcc/testsuite/gcc.target/aarch64/pr110625_3.c | 34 +++++++++++++++++++ 2 files changed, 35 insertions(+), 1 deletion(-) create mode 100644 gcc/testsuite/gcc.target/aarch64/pr110625_3.c diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index d4d76025545..5b8d8fa8e2d 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -16776,7 +16776,7 @@ aarch64_adjust_stmt_cost (vect_cost_for_stmt kind, = stmt_vec_info stmt_info, static bool aarch64_force_single_cycle (vec_info *vinfo, stmt_vec_info stmt_info) { - if (!STMT_VINFO_LIVE_P (stmt_info)) + if (!STMT_VINFO_REDUC_DEF (stmt_info)) return false; auto reduc_info =3D info_for_reduction (vinfo, stmt_info); diff --git a/gcc/testsuite/gcc.target/aarch64/pr110625_3.c b/gcc/testsuite/= gcc.target/aarch64/pr110625_3.c new file mode 100644 index 00000000000..35a50290cb0 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/pr110625_3.c @@ -0,0 +1,34 @@ +/* { dg-do compile } */ +/* { dg-options "-O3 -mcpu=3Dneoverse-n2" } */ + +/* Avoid ICE on empty reduction def in single_defuse_cycle. + + E.g. + [local count: 858993456]: + # sum_18 =3D PHI + sum.0_5 =3D (unsigned int) sum_18; + _6 =3D _4 + sum.0_5; <-- it is "live" but doesn't have reduction = def + sum_15 =3D (int) _6; + ... + if (ivtmp_29 !=3D 0) + goto ; [75.00%] + else + goto ; [25.00%] + + [local count: 644245086]: + goto ; [100.00%] + + [local count: 214748368]: + # _31 =3D PHI <_6(3)> + _8 =3D _31 >> 1; +*/ + +int +f (unsigned int *tmp) +{ + int sum =3D 0; + for (int i =3D 0; i < 4; i++) + sum +=3D tmp[i]; + + return (unsigned int) sum >> 1; +} -- 2.34.1 ________________________________________ From: Hao Liu OS Sent: Tuesday, August 1, 2023 17:43 To: Richard Sandiford Cc: Richard Biener; GCC-patches@gcc.gnu.org Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by= multiplying count [PR110625] Hi Richard, This is a quick fix to the several ICEs. It seems even STMT_VINFO_LIVE_P i= s true, some reduct stmts still don't have REDUC_DEF. So I change the chec= k to STMT_VINFO_REDUC_DEF. Is it OK for trunk? --- Fix the ICEs on empty reduction define. Even STMT_VINFO_LIVE_P is true, so= me reduct stmts still don't have definition. gcc/ChangeLog: PR target/110625 * config/aarch64/aarch64.cc (aarch64_force_single_cycle): check STMT_VINFO_REDUC_DEF to avoid failures in info_for_reduction --- gcc/config/aarch64/aarch64.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc index d4d76025545..5b8d8fa8e2d 100644 --- a/gcc/config/aarch64/aarch64.cc +++ b/gcc/config/aarch64/aarch64.cc @@ -16776,7 +16776,7 @@ aarch64_adjust_stmt_cost (vect_cost_for_stmt kind, = stmt_vec_info stmt_info, static bool aarch64_force_single_cycle (vec_info *vinfo, stmt_vec_info stmt_info) { - if (!STMT_VINFO_LIVE_P (stmt_info)) + if (!STMT_VINFO_REDUC_DEF (stmt_info)) return false; auto reduc_info =3D info_for_reduction (vinfo, stmt_info); -- 2.40.0 ________________________________________ From: Richard Sandiford Sent: Monday, July 31, 2023 17:11 To: Hao Liu OS Cc: Richard Biener; GCC-patches@gcc.gnu.org Subject: Re: [PATCH] AArch64: Do not increase the vect reduction latency by= multiplying count [PR110625] Hao Liu OS writes: >> Which test case do you see this for? The two tests in the patch still >> seem to report correct latencies for me if I make the change above. > > Not the newly added tests. It is still the existing case causing the pre= vious ICE (i.e. assertion problem): gcc.target/aarch64/sve/cost_model_13.c. > > It's not the test case itself failed, but the dump message of vect says t= he "reduction latency" is 0: > > Before the change: > cost_model_13.c:7:21: note: Original vector body cost =3D 6 > cost_model_13.c:7:21: note: Scalar issue estimate: > cost_model_13.c:7:21: note: load operations =3D 1 > cost_model_13.c:7:21: note: store operations =3D 0 > cost_model_13.c:7:21: note: general operations =3D 1 > cost_model_13.c:7:21: note: reduction latency =3D 1 > cost_model_13.c:7:21: note: estimated min cycles per iteration =3D 1.0= 00000 > cost_model_13.c:7:21: note: estimated cycles per vector iteration (for= VF 8) =3D 8.000000 > cost_model_13.c:7:21: note: Vector issue estimate: > cost_model_13.c:7:21: note: load operations =3D 1 > cost_model_13.c:7:21: note: store operations =3D 0 > cost_model_13.c:7:21: note: general operations =3D 1 > cost_model_13.c:7:21: note: reduction latency =3D 2 > cost_model_13.c:7:21: note: estimated min cycles per iteration =3D 2.0= 00000 > > After the change: > cost_model_13.c:7:21: note: Original vector body cost =3D 6 > cost_model_13.c:7:21: note: Scalar issue estimate: > cost_model_13.c:7:21: note: load operations =3D 1 > cost_model_13.c:7:21: note: store operations =3D 0 > cost_model_13.c:7:21: note: general operations =3D 1 > cost_model_13.c:7:21: note: reduction latency =3D 0 <--- seems= not consistent with above result > cost_model_13.c:7:21: note: estimated min cycles per iteration =3D 1.0= 00000 > cost_model_13.c:7:21: note: estimated cycles per vector iteration (for= VF 8) =3D 8.000000 > cost_model_13.c:7:21: note: Vector issue estimate: > cost_model_13.c:7:21: note: load operations =3D 1 > cost_model_13.c:7:21: note: store operations =3D 0 > cost_model_13.c:7:21: note: general operations =3D 1 > cost_model_13.c:7:21: note: reduction latency =3D 0 <--- seems= not consistent with above result > cost_model_13.c:7:21: note: estimated min cycles per iteration =3D 1.0= 00000 <--- seems not consistent with above result > > BTW. this should be caused by the reduction stmt is not live, which indic= ates whether this stmts is part of a computation whose result is used outsi= de the loop (tree-vectorized.h:1204): > : > # res_18 =3D PHI > # i_20 =3D PHI > _1 =3D (long unsigned int) i_20; > _2 =3D _1 * 2; > _3 =3D x_14(D) + _2; > _4 =3D *_3; > _5 =3D (unsigned short) _4; > res.0_6 =3D (unsigned short) res_18; > _7 =3D _5 + res.0_6; <-- This is not live, = may be caused by the below type cast stmt. > res_15 =3D (short int) _7; > i_16 =3D i_20 + 1; > if (n_11(D) > i_16) > goto ; > else > goto ; > > : > goto ; Ah, I see, thanks. My concern was: if requiring !STMT_VINFO_LIVE_P stmts can cause "normal" reductions to have a latency of 0, could the same thing happen for single-cycle reductions? But I suppose the answer is "no". Introducing a cast like the above would cause reduc_chain_length > 1, and so: if (ncopies > 1 && (STMT_VINFO_RELEVANT (stmt_info) <=3D vect_used_only_live) && reduc_chain_length =3D=3D 1 && loop_vinfo->suggested_unroll_factor =3D=3D 1) single_defuse_cycle =3D true; wouldn't trigger. Which makes the single-cycle thing a bit hit-and-miss... So yeah, I agree the patch is safe after all. Please split the check out into a helper though, to avoid the awkward formatting: /* Return true if STMT_INFO is part of a reduction that has the form: r =3D r op ...; r =3D r op ...; with the single accumulator being read and written multiple times. */ static bool aarch64_force_single_cycle (vec_info *vinfo, stmt_vec_info stmt_info) { if (!STMT_VINFO_LIVE_P (stmt_info)) return false; auto reduc_info =3D info_for_reduction (vinfo, stmt_info); return STMT_VINFO_FORCE_SINGLE_CYCLE (reduc_info); } OK with that change, thanks. Richard