From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by sourceware.org (Postfix) with ESMTPS id 58F9F384AB52 for ; Tue, 25 Jun 2024 02:00:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 58F9F384AB52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 58F9F384AB52 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=198.175.65.17 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1719280824; cv=pass; b=O/kLmZjnFa/jaLAJGGHDzlcmZb2YyPWbdCcz8nCBT5TjO43awLhihF6CdChPhiNR+ATpr5Kvk45MdL9oMDpi8aXT0LKTm66ywuu/quBEOAAZtJBnHjESFOw/ELqSyMtn07W3/GwgIO8Dn9/EQxkFyStIVpyy0ocrhp4uLPvjnoc= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1719280824; c=relaxed/simple; bh=D9A3RNAhUcgGUQrjTeMShnSZ7+PzLbS6fnwCNWz6LsY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ToeKP5aFqvLw2j/2ZUOFwIqpevl6jfCfw1WxhQ2SCFaki8WyAGdkgD2XciREPdypqkoElrEFCKZJ1iRNdnAypKs7PCtZbhPj+oMLNrNY7ic4SGsP+c7s8NguXxKmqPPMz+c/638ukbdVnxCgpOTHOsnywmfmBCy7OJeGmw6k+4E= ARC-Authentication-Results: i=2; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1719280822; x=1750816822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=D9A3RNAhUcgGUQrjTeMShnSZ7+PzLbS6fnwCNWz6LsY=; b=Wi+x1/0ncZ9IfhCiHi8uN5H/VzHPsZHXuF0fXI+QRjj+E5vQi1moP/Gn 0Cy1XqIWfCsg2OeXJrxNkqkiHaQYilesXQlaTHMFq37CqU6EpYecwsp+j nRYEQtMyiplETwc3yDcJTgwkMFHoidmaJb9BPCiiwOiE9xVjfEV03wt2H kr0mdq5BjVP9mXxCd5nLQ73g8kTfogYvVpifXwRuYqCy7XvWrm3BWeXRG S0kxZNZNOs2khcIjiAlhL2IG6Q672q17FWs9W2f0OB6HcMUzm4hI1Lsy+ rOv/Vx5SqTIL7JcnVdh55NnJiOREp2vp5OE+yfixH1Vqtn980GYOiHWqC Q==; X-CSE-ConnectionGUID: r5iTpAUkT8+mvH5Dho9W+A== X-CSE-MsgGUID: RFpuF4/kRZa1f8KipjUTsQ== X-IronPort-AV: E=McAfee;i="6700,10204,11113"; a="16407446" X-IronPort-AV: E=Sophos;i="6.08,263,1712646000"; d="scan'208";a="16407446" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2024 19:00:19 -0700 X-CSE-ConnectionGUID: BDMZxmZ4R6CqkTf4v6tqFQ== X-CSE-MsgGUID: BYnLy2TYSoGJUEeS+WkwOg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,263,1712646000"; d="scan'208";a="43472268" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by fmviesa008.fm.intel.com with ESMTP/TLS/AES256-GCM-SHA384; 24 Jun 2024 19:00:18 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 24 Jun 2024 19:00:18 -0700 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Mon, 24 Jun 2024 19:00:17 -0700 Received: from ORSEDG602.ED.cps.intel.com (10.7.248.7) by orsmsx612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39 via Frontend Transport; Mon, 24 Jun 2024 19:00:17 -0700 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.177) by edgegateway.intel.com (134.134.137.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 24 Jun 2024 19:00:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T4G62GlMseEl8SZI7of45qpxnPP1ORl5yiJiZUowQmtAxhLxet1UHE/o9j7wla2rQASxAgqgXgXZis8rQ46H2xTBlT9TmTGhwyKeQdLNpZFjBXODTeUaSimUYjM9fto1giHLZJjVHYPLXKehfCQvKCBXWVI4P9rDMT3k67B9dIfNC6IiuVIGLwdPnIJU96X6UFEOSnbQtJUqALAh4D7gQLlwO5TMJmymRXNLsoz/i8ZTckK556Lo9z1QAHor4OdiScW7wAtqG5/TiMvWQuIOvts7osAVNS2hUBE3zETHPdnTY6bsk2Hab0wJl2MUfT7QW73cjhz4txggHQeLePQAqg== 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=QhWxkiixkKdM1WVBYDLQden9Sjp09qhSBdrDFO9jx9c=; b=VhZ8FDCBJAI8fKZ0wWyvbbSoMh7hV08owoq/DiBbM1nqZs7+5LdKfL/bx4JqDzjNUIIWeVNVQFtgyFU9mSG3MOFlr09N/Ixhu6VYVnKrofdnIMPfaCDGW6e0HElJ7wYUgJRfTzOKf/ZiGYk+BDdaLK6YW88T09G4xtSbHW22VJp3bzrhgKAJmTTAcW9XjHfYoYKefe9q0BC3EZoHb6rYOMDZXSp5GvE6fUAuU709c2POcUdAoPvTIFt+tC8OSJGbH0Z709+AQzXF8fcLb6QT1anfiu0VfHhR+hVjH8RUH1nca+VEFAjVSZMFw76iw1cVYiF+r7TavWT3kKxslXPn7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none Received: from SJ0PR11MB5940.namprd11.prod.outlook.com (2603:10b6:a03:42f::18) by DM4PR11MB6192.namprd11.prod.outlook.com (2603:10b6:8:a9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7698.28; Tue, 25 Jun 2024 02:00:14 +0000 Received: from SJ0PR11MB5940.namprd11.prod.outlook.com ([fe80::ef48:2bc0:f2ae:bbb]) by SJ0PR11MB5940.namprd11.prod.outlook.com ([fe80::ef48:2bc0:f2ae:bbb%3]) with mapi id 15.20.7698.025; Tue, 25 Jun 2024 02:00:14 +0000 From: "Hu, Lin1" To: Tamar Christina , Richard Biener CC: "gcc-patches@gcc.gnu.org" , "Liu, Hongtao" , "ubizjak@gmail.com" Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int -> int, float -> float and int <-> float. Thread-Topic: [PATCH 1/3 v3] vect: generate suitable convert insn for int -> int, float -> float and int <-> float. Thread-Index: AQHau8vr6yycmMZa8kKFnX1kpTUP0rHNckcAgALzc/CABog/AIAAG3GAgAC2TXA= Date: Tue, 25 Jun 2024 02:00:14 +0000 Message-ID: References: <20240611064901.37222-1-lin1.hu@intel.com> <3n8ps3n3-7r70-75q1-436p-8n48r435o6qn@fhfr.qr> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR11MB5940:EE_|DM4PR11MB6192:EE_ x-ms-office365-filtering-correlation-id: 1ca34b70-8d34-450f-68e6-08dc94ba8e06 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230037|376011|366013|1800799021|38070700015; x-microsoft-antispam-message-info: =?us-ascii?Q?GzBtUGMvVZ4jbMh2tjZ2zDs3ivjLWyHGGuENKd+w/XiItBnHCICwyoNSBUEC?= =?us-ascii?Q?FYd6lw/ZA2AW8jWfAZUv4ytgyalpW9uDqVYkAXdGfbP4LvTtyqUQL9zzG40m?= =?us-ascii?Q?/P0zBBU/MPpYJrQTv0AzMJl4Y8hEO401sMIiuX938wEsVfD2SrqFlGnyeJjN?= =?us-ascii?Q?yV9KsHJKj6iq45bl2VlA0tblbsXLdFyj7TCqcbbE+YRe3GIqfMa4cLI2CjFk?= =?us-ascii?Q?lITQ0PjOnGMHiAs5Em/V6y51/poUMXhdLCs7mRPOUC2IJF75fltWhN6T0MJT?= =?us-ascii?Q?pkmVRH8jVcRhdHp2JRhWqCk3BE9PE9MufGmAgVZGUOgjuWd7xNaggScWrcU7?= =?us-ascii?Q?Zh8B1+9v1/WcxvVhYigSgiDBitiIeZ0CYc+EqjrIyS2cuoHpz+93cyTVW8n/?= =?us-ascii?Q?fmGXtMAOAooNqNtSsYFcVDiy3tJgTzjIHC76CfLu3iDOe/pjR4it5PXs7F+I?= =?us-ascii?Q?psmQ0Kp5Ae4cWLm/oUu/DLy4Ib3xNGmKVa7DLbmKfHZAYKbSXW7lRkeMqr73?= =?us-ascii?Q?6cCl5HQa+5BLztPUndmovRdoM0jnShovmfsmLTUHtw5yK5gXeUg8xJ1S02aR?= =?us-ascii?Q?Pa6Yj7YluVyEUjPmCemA490xhqtN3AU+ZWIyG42MQZp2IQ2YdnWvIYkBZGym?= =?us-ascii?Q?FWVSawxP26e8fV9Q88px4emWrn8Xz9BUNeFDx7qFGSLTTJZ42AqGLlcLBua8?= =?us-ascii?Q?yaQYhVz3s8gkGpe5fHq2vBjZv62A9G5fqjkr/7s6/M72Mlp7K524FNRxrodg?= =?us-ascii?Q?2aWaJS37VRwiLXkIqYcG26/oXIYa85xoEXNlAK+Bq5ZELnNwiy+BEM/2Y+FW?= =?us-ascii?Q?eWr4xAdmnAhwjAKPwUDSH3hdOpX6tsThHLCuX7l/954e0Iw61dceT1JbiI7v?= =?us-ascii?Q?REoRGtcHVMDXKii1sd8Du1jobiIWTTUz+wB43QTAwcl+bv3VW3EO//gce+1q?= =?us-ascii?Q?r2xWxHV3VTfpKAaGv9LpOx5UOsVFyawXR+mL0jX68pcIT3k/+aIQEzdy+f/m?= =?us-ascii?Q?LXcQoPOENNPeFcXnov8SuZ+R+FzgiC25gZcsQUMY0GPtNhdkKCMcvbQZIZNY?= =?us-ascii?Q?CEfIzqFIaFo8N6vb9weuqBNct92GPCEK1Yg6EjzpgGmxCn6QQAQ15OGTmEYG?= =?us-ascii?Q?LE4k2V/JnQOXvjmaFxZ0e3zDpv+Rg28JDDZuYdEnm2lJifb7hlnDzbMYxaUE?= =?us-ascii?Q?6bRcxEG3HJg3MoV8jKwoslM5HeiJ+51LvL17ZQ5bHXXhPjfLBXcS8e7jkNHL?= =?us-ascii?Q?numnvA56JNooVx/ypvCyA1Tcv2vuUzeNpM7eTrG7gOPaMRaA/RNKcUdNNj7p?= =?us-ascii?Q?7QFwbfltBWsEdCh1ER4hkDyuys2OKWvAduoqltqXPBLz5HV8Mym/FpiXrp2Z?= =?us-ascii?Q?8cO/9PI=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SJ0PR11MB5940.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230037)(376011)(366013)(1800799021)(38070700015);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PiSbirik7z9biFr8zIWdY5yoiZlNXTQZK6io0dSMMswdZeoWPvte8Hprqo4a?= =?us-ascii?Q?ZWqMH8p5IxOJRL6WXXLuYAwaHjHyQpFfQjvPpZRCYexViGviDa2WjdYxnVQi?= =?us-ascii?Q?XQdhPRznR+rAcd8VSOupDjPp7hsKoiPKTqpwEdryCUHLOvloR6Hr2/Bd4QA+?= =?us-ascii?Q?Irx0AIdpUQe0uU0PiJDtVSss3KQVdUAEoBiaKXGfokWMD3iTY+GzhLx1Crau?= =?us-ascii?Q?BBGE1lBhV/sp8cFtybkHdUWvWZdN1uoGQPHHdZWr4jFxDptooFfCUCUSv0LP?= =?us-ascii?Q?38lVFO0j5CQP36EmXHAk3krS47LWY093x3S0yLnmk7/6tDYMKqCmUAu+nhx8?= =?us-ascii?Q?sSKpzlWNK07N+oiCobVPiRSzwDevdGQs6fgp6bZMfw4Zl1kRqkfRZshWvBz/?= =?us-ascii?Q?4Er+wwH+tuWwbQObznyyKjolRXXUbTe3mxAbdaYTJdNN0ZB3XR/3kd1YKtfI?= =?us-ascii?Q?AzaPVeaCR4ul3Fs2SwEqup87eMT6aWid758xN1UhfLH092jE/AlWCI0L4Kbx?= =?us-ascii?Q?miemMABRgD6H7lIXKEepiaP+zuMsOalXfgk/kfRsdeYzmx7hEVQt3cOB3bW3?= =?us-ascii?Q?9hGtOxZMqdvZexxQwBDC6fNeBJRVBz2C99XokfNX5HskNmX0LowJo4kFa3T0?= =?us-ascii?Q?VzONMnGd2Pupww/NwcNH30CjwMXzCyhFRfdZbd3yWmNdb6zG7h1/6qOMYHbu?= =?us-ascii?Q?kLiiQPfcL9YPlZVWFmMQCEqgPVBgWFWdmfycUl0tyeMDrq2aVYR4TFNQzBE2?= =?us-ascii?Q?AfiGWihjowkUsBJxlF2+WEhrwUlgKLleuu3wJ+YTw10WYL82nVPE1TNFZeRl?= =?us-ascii?Q?YQ2k5QggbTzZdFzBc/mbfakj9HTwwrN8LwmiHG+wn5ObobAgp4CMErTeKNcj?= =?us-ascii?Q?AIcoN5pRotChFo0MLgvOmcenDJy4EAIH9s3DK6qgnj8Ksjo8qqardyToLQS/?= =?us-ascii?Q?EGCK7blyOQUmS5hmxX+45snJtskx/OQL4ovCnxu2fMsXURjgItsicmNiYf8r?= =?us-ascii?Q?7VZZCBl8S1c/IlSRx/jr6sa8Lpd6PciNjUr5BTjtflmp5dcz3vxKaZon1jmv?= =?us-ascii?Q?KbmuV60Lmr7Eha/Rh9jK8nwuGth21fN2506oGjjcoHbVXtY02/TLig7f4SMN?= =?us-ascii?Q?9l5QTmJLNeYpUGMXwTelt6YlcMqwE92NIdjxXHZFuWfTROO+r+6bCAFo5ilU?= =?us-ascii?Q?wpKGAhRDEafUAm9Z+ZpD25zk/dx//9d0Zti0gOQRVUPZwxQ8MKmOtFiGjj7K?= =?us-ascii?Q?cKUZTYLGoSUsP/dqCbLZy7M+ud58WxBvsQWAcKlTVdObJuE6IFq4ocaDPTIi?= =?us-ascii?Q?fnvny07TL+mMUhnANjfw64ACp0vHHaAmymnb2J2CpCHFxicd0eeQmMUqPl+7?= =?us-ascii?Q?1qqA8X/cLghZRx7vrVjfsYz4XE5mDXmm68FgWF2BPKwM8c0tO8s2+N7R3wjH?= =?us-ascii?Q?zG+i+SXruZ5sek3gEBf4hDq6893RV2briv4mfIlz0Ab91ZsJAFW2c9yO4UU0?= =?us-ascii?Q?Y0Y14Pc4venxyiXK+csoYil75qE7O3iGZTNbCNjyELW1KpYlGhK7akU8b3CF?= =?us-ascii?Q?55E1xptK1ohHZaw3cFQ=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB5940.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ca34b70-8d34-450f-68e6-08dc94ba8e06 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2024 02:00:14.6811 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gt53g3dsfeOpylw7d5rwIN1cmpE5hnoRE5xiTUEnCClp+3x8S8Zqrw4Ab71kaVDrtte0BEAFxbOcdPRRUY7ssw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6192 X-OriginatorOrg: intel.com X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_NONE,TXREP 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: Tamar Christina > Sent: Monday, June 24, 2024 10:12 PM > To: Richard Biener ; Hu, Lin1 > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ; > ubizjak@gmail.com > Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for int = -> int, > float -> float and int <-> float. >=20 > > -----Original Message----- > > From: Richard Biener > > Sent: Monday, June 24, 2024 1:34 PM > > To: Hu, Lin1 > > Cc: gcc-patches@gcc.gnu.org; Liu, Hongtao ; > > ubizjak@gmail.com > > Subject: RE: [PATCH 1/3 v3] vect: generate suitable convert insn for > > int -> int, float > > -> float and int <-> float. > > > > On Thu, 20 Jun 2024, Hu, Lin1 wrote: > > > > > > > else if (ret_elt_bits > arg_elt_bits) > > > > > modifier =3D WIDEN; > > > > > > > > > > + if (supportable_convert_operation (code, ret_type, arg_type, &= code1)) > > > > > + { > > > > > + g =3D gimple_build_assign (lhs, code1, arg); > > > > > + gsi_replace (gsi, g, false); > > > > > + return; > > > > > + } > > > > > > > > Given the API change I suggest below it might make sense to have > > > > supportable_indirect_convert_operation do the above and represent > > > > it as > > single- > > > > step conversion? > > > > > > > > > > OK, if you want to supportable_indirect_convert_operation can do > > > something like supportable_convert_operation, I'll give it a try. > > > This functionality is really the part that this function can cover. > > > But this would require some changes not only the API change, because > > > supportable_indirect_convert_operation originally only supported > > > Float > > > -> Int or Int ->Float. > > > > I think I'd like to see a single API to handle direct and > > (multi-)indirect-level converts that operate on vectors with all the > > same number of lanes. > > > > > > > > > > > + code_helper code2 =3D ERROR_MARK, code3 =3D ERROR_MARK; > > > > > + int multi_step_cvt =3D 0; > > > > > + vec interm_types =3D vNULL; > > > > > + if (supportable_indirect_convert_operation (NULL, > > > > > + code, > > > > > + ret_type, arg_type, > > > > > + &code2, &code3, > > > > > + &multi_step_cvt, > > > > > + &interm_types, arg)) > > > > > + { > > > > > + new_rhs =3D make_ssa_name (interm_types[0]); > > > > > + g =3D gimple_build_assign (new_rhs, (tree_code) code3, arg= ); > > > > > + gsi_insert_before (gsi, g, GSI_SAME_STMT); > > > > > + g =3D gimple_build_assign (lhs, (tree_code) code2, new_rhs= ); > > > > > + gsi_replace (gsi, g, false); > > > > > + return; > > > > > + } > > > > > + > > > > > if (modifier =3D=3D NONE && (code =3D=3D FIX_TRUNC_EXPR || cod= e =3D=3D > > > > FLOAT_EXPR)) > > > > > { > > > > > - if (supportable_convert_operation (code, ret_type, arg_typ= e, > &code1)) > > > > > - { > > > > > - g =3D gimple_build_assign (lhs, code1, arg); > > > > > - gsi_replace (gsi, g, false); > > > > > - return; > > > > > - } > > > > > /* Can't use get_compute_type here, as > supportable_convert_operation > > > > > doesn't necessarily use an optab and needs two arguments. */ > > > > > tree vec_compute_type > > > > > diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc > > > > > index 05a169ecb2d..0aa608202ca 100644 > > > > > --- a/gcc/tree-vect-stmts.cc > > > > > +++ b/gcc/tree-vect-stmts.cc > > > > > @@ -5175,7 +5175,7 @@ vectorizable_conversion (vec_info *vinfo, > > > > > tree scalar_dest; > > > > > tree op0, op1 =3D NULL_TREE; > > > > > loop_vec_info loop_vinfo =3D dyn_cast (vinfo); > > > > > - tree_code tc1, tc2; > > > > > + tree_code tc1; > > > > > code_helper code, code1, code2; > > > > > code_helper codecvt1 =3D ERROR_MARK, codecvt2 =3D ERROR_MARK; > > > > > tree new_temp; > > > > > @@ -5384,92 +5384,17 @@ vectorizable_conversion (vec_info *vinfo, > > > > > break; > > > > > } > > > > > > > > > > - /* For conversions between float and integer types try whe= ther > > > > > - we can use intermediate signed integer types to support the > > > > > - conversion. */ > > > > > - if (GET_MODE_SIZE (lhs_mode) !=3D GET_MODE_SIZE (rhs_mode) > > > > > - && (code =3D=3D FLOAT_EXPR || > > > > > - (code =3D=3D FIX_TRUNC_EXPR && !flag_trapping_math))) > > > > > - { > > > > > - bool demotion =3D GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE > > > > (lhs_mode); > > > > > - bool float_expr_p =3D code =3D=3D FLOAT_EXPR; > > > > > - unsigned short target_size; > > > > > - scalar_mode intermediate_mode; > > > > > - if (demotion) > > > > > - { > > > > > - intermediate_mode =3D lhs_mode; > > > > > - target_size =3D GET_MODE_SIZE (rhs_mode); > > > > > - } > > > > > - else > > > > > - { > > > > > - target_size =3D GET_MODE_SIZE (lhs_mode); > > > > > - if (!int_mode_for_size > > > > > - (GET_MODE_BITSIZE (rhs_mode), 0).exists > > > > (&intermediate_mode)) > > > > > - goto unsupported; > > > > > - } > > > > > - code1 =3D float_expr_p ? code : NOP_EXPR; > > > > > - codecvt1 =3D float_expr_p ? NOP_EXPR : code; > > > > > - opt_scalar_mode mode_iter; > > > > > - FOR_EACH_2XWIDER_MODE (mode_iter, intermediate_mode) > > > > > - { > > > > > - intermediate_mode =3D mode_iter.require (); > > > > > - > > > > > - if (GET_MODE_SIZE (intermediate_mode) > target_size) > > > > > - break; > > > > > - > > > > > - scalar_mode cvt_mode; > > > > > - if (!int_mode_for_size > > > > > - (GET_MODE_BITSIZE (intermediate_mode), 0).exists > > > > (&cvt_mode)) > > > > > - break; > > > > > - > > > > > - cvt_type =3D build_nonstandard_integer_type > > > > > - (GET_MODE_BITSIZE (cvt_mode), 0); > > > > > - > > > > > - /* Check if the intermediate type can hold OP0's range. > > > > > - When converting from float to integer this is not necessary > > > > > - because values that do not fit the (smaller) target type are > > > > > - unspecified anyway. */ > > > > > - if (demotion && float_expr_p) > > > > > - { > > > > > - wide_int op_min_value, op_max_value; > > > > > - if (!vect_get_range_info (op0, &op_min_value, > > > > &op_max_value)) > > > > > - break; > > > > > - > > > > > - if (cvt_type =3D=3D NULL_TREE > > > > > - || (wi::min_precision (op_max_value, SIGNED) > > > > > - > TYPE_PRECISION (cvt_type)) > > > > > - || (wi::min_precision (op_min_value, SIGNED) > > > > > - > TYPE_PRECISION (cvt_type))) > > > > > - continue; > > > > > - } > > > > > - > > > > > - cvt_type =3D get_vectype_for_scalar_type (vinfo, cvt_type= , slp_node); > > > > > - /* This should only happened for SLP as long as loop vect= orizer > > > > > - only supports same-sized vector. */ > > > > > - if (cvt_type =3D=3D NULL_TREE > > > > > - || maybe_ne (TYPE_VECTOR_SUBPARTS (cvt_type), nunits_in) > > > > > - || !supportable_convert_operation ((tree_code) code1, > > > > > - vectype_out, > > > > > - cvt_type, &tc1) > > > > > - || !supportable_convert_operation ((tree_code) codecvt1, > > > > > - cvt_type, > > > > > - vectype_in, &tc2)) > > > > > - continue; > > > > > - > > > > > - found_mode =3D true; > > > > > - break; > > > > > - } > > > > > + if (supportable_indirect_convert_operation (vinfo, > > > > > + code, > > > > > + vectype_out, > > > > > + vectype_in, > > > > > + &code1, > > > > > + &codecvt1, > > > > > + &multi_step_cvt, > > > > > + &interm_types, > > > > > + op0,slp_node)) > > > > > + break; > > > > > > > > > > - if (found_mode) > > > > > - { > > > > > - multi_step_cvt++; > > > > > - interm_types.safe_push (cvt_type); > > > > > - cvt_type =3D NULL_TREE; > > > > > - code1 =3D tc1; > > > > > - codecvt1 =3D tc2; > > > > > - break; > > > > > - } > > > > > - } > > > > > /* FALLTHRU */ > > > > > unsupported: > > > > > if (dump_enabled_p ()) > > > > > @@ -14626,6 +14551,153 @@ supportable_narrowing_operation > > > > (code_helper code, > > > > > return false; > > > > > } > > > > > > > > > > +/* Function supportable_indirect_convert_operation > > > > > + > > > > > + Check whether an operation represented by the code CODE is tw= o > > > > > + convert operations that are supported by the target platform = in > > > > > + vector form (i.e., when operating on arguments of type VECTYP= E_IN > > > > > + producing a result of type VECTYPE_OUT). > > > > > + > > > > > + Convert operations we currently support directly are > > > > > + FIX_TRUNC and > > FLOAT. > > > > > + This function checks if these operations are supported > > > > > + by the target platform directly (via vector tree-codes). > > > > > + > > > > > + Output: > > > > > + - CODE1 is the code of a vector operation to be used when > > > > > + converting the operation in the first step, if available. > > > > > + - CODE2 is the code of a vector operation to be used when > > > > > + converting the operation in the second step, if available. > > > > > + - MULTI_STEP_CVT determines the number of required > > > > > + intermediate steps > > > > in > > > > > + case of multi-step conversion (like int->short->char - in tha= t case > > > > > + MULTI_STEP_CVT will be 1). In the function, it should be 1. > > > > > + - INTERM_TYPES contains the intermediate type required to per= form > the > > > > > + convert operation (short in the above example). */ > > > > > +bool > > > > > +supportable_indirect_convert_operation (vec_info *vinfo, > > > > > + code_helper code, > > > > > + tree vectype_out, > > > > > + tree vectype_in, > > > > > + code_helper *code1, > > > > > + code_helper *code2, > > > > > + int *multi_step_cvt, > > > > > + vec *interm_types, > > > > > > > > This API is somewhat awkward, as we're inventing a new one I guess > > > > we can do better. I think we want > > > > > > > > vec > *converts, > > > > > > > > covering all code1, code2, multi_step_cvt and interm_types with > > > > the > > conversion > > > > sequence being > > > > > > > > converts[0].first tem0 =3D converts[0].second op0; > > > > converts[1].first tem1 =3D converts[1].second tem; > > > > > > > > > > That's great, this really makes the function work better. > > > > > > > > > > > ... while converts.length () determines the length of the chain, > > > > one being a > > direct > > > > conversion where then converts[0].first is vectype_out. That > > > > would allow double -> char to go double -> float -> int -> short ->= char for > example. > > > > > > > > > > I'm trying to determine the requirements, do you want this function > > > to support multiple conversions (the current implementation just > > > does a two-step conversion, like double -> char, which becomes > > > double -> int -> char). Actually we should be able to do all > > > conversions in two steps, if we have some suitable instructions. I > > > can't think of a scenario where multiple conversions are needed yet. > > > Could you give me some examples? Of course, I could tweak this > > > feature in advance if it is for future consideration. > > > > I think the API should support multi-level, not only two levels. The > > implementation doesn't need to cover that case unless we run into such > > a requirement. Usually vector ISAs allow 2x integer > > widening/shortening but not 4x, so a VnDImode -> VnQImode conversion > > would need to go via VnSImode and VnHImode (of course some targets > > might "help" the vectorizer by providing a VnDImode -> VnQImode > > pattern that does the intermediate conversions behind the vectorizers > > back). But yes, the original motivation for the vectorizer code was > > that float<->int conversions are limited. > > >=20 > I have a similar patch in this area but instead looking at unsigned int <= -> double > conversion. I would want to avoid complicating this area too much so it= would > be good if the API doesn't care about sign either and allows the target t= o choose > the operation mode? >=20 > My current patch has a backend target hook that asks if the current widen= ing is > Preferred as multilevel or single level. For single level I just generat= e > VEC_PERM_EXPRs with a zero register. >=20 > Just wanted to bring it up in case we can have a coherent story around th= is > conversions. > This is the current API. 14579 bool 14580 supportable_indirect_convert_operation (code_helper code, 14581 tree vectype_out, 14582 tree vectype_in, 14583 vec > *converts, 14584 tree op0) This API doesn't care about sign, whether double to char or unsigned char w= ill be converted to int first in my opinion. About the backend target hook, I guess you use targetm.* to determine the t= arget to choose the operation mode, if yes, I think the API is ok for now, = you can use targetm to determine the operation mode and output through conv= erts. What do you think? BRs, Lin=20 > > > > > > > > > > > > > > > + tree op0, > > > > > + slp_tree slp_node) > > > > > > > > I would like to avoid passing VINFO and SLP_NODE here, see below. > > > > The same is true for OP0 where the existing use is wrong for SLP > > > > already, but I guess that can stay for now (I opened PR115538 about= the > wrong-code issue). > > > > > > > > > > Thanks, I have removed them. > > > > > > > > > > > > +{ > > > > > + bool found_mode =3D false; > > > > > + scalar_mode lhs_mode =3D GET_MODE_INNER (TYPE_MODE > > > > > +(vectype_out)); > > > > > + scalar_mode rhs_mode =3D GET_MODE_INNER (TYPE_MODE > > > > > +(vectype_in)); > > > > > + opt_scalar_mode mode_iter; > > > > > + tree_code tc1, tc2; > > > > > + > > > > > + tree cvt_type =3D NULL_TREE; > > > > > + poly_uint64 nelts =3D TYPE_VECTOR_SUBPARTS (vectype_in); > > > > > + > > > > > + (*multi_step_cvt) =3D 0; > > > > > + /* For conversions between float and integer types try whether > > > > > + we can use intermediate signed integer types to support the > > > > > + conversion. */ > > > > > + if (GET_MODE_SIZE (lhs_mode) !=3D GET_MODE_SIZE (rhs_mode) > > > > > + && (code =3D=3D FLOAT_EXPR > > > > > + || (code =3D=3D FIX_TRUNC_EXPR && !flag_trapping_math))) > > > > > + { > > > > > + bool demotion =3D GET_MODE_SIZE (rhs_mode) > GET_MODE_SIZE > > > > (lhs_mode); > > > > > + bool float_expr_p =3D code =3D=3D FLOAT_EXPR; > > > > > + unsigned short target_size; > > > > > + scalar_mode intermediate_mode; > > > > > + if (demotion) > > > > > + { > > > > > + intermediate_mode =3D lhs_mode; > > > > > + target_size =3D GET_MODE_SIZE (rhs_mode); > > > > > + } > > > > > + else > > > > > + { > > > > > + target_size =3D GET_MODE_SIZE (lhs_mode); > > > > > + if (!int_mode_for_size > > > > > + (GET_MODE_BITSIZE (rhs_mode), 0).exists > (&intermediate_mode)) > > > > > + return false; > > > > > + } > > > > > + *code1 =3D float_expr_p ? code : NOP_EXPR; > > > > > + *code2 =3D float_expr_p ? NOP_EXPR : code; > > > > > + opt_scalar_mode mode_iter; > > > > > + FOR_EACH_2XWIDER_MODE (mode_iter, intermediate_mode) > > > > > + { > > > > > + intermediate_mode =3D mode_iter.require (); > > > > > + > > > > > + if (GET_MODE_SIZE (intermediate_mode) > target_size) > > > > > + break; > > > > > + > > > > > + scalar_mode cvt_mode; > > > > > + if (!int_mode_for_size > > > > > + (GET_MODE_BITSIZE (intermediate_mode), 0).exists > (&cvt_mode)) > > > > > + break; > > > > > + > > > > > + cvt_type =3D build_nonstandard_integer_type > > > > > + (GET_MODE_BITSIZE (cvt_mode), 0); > > > > > + > > > > > + /* Check if the intermediate type can hold OP0's range. > > > > > + When converting from float to integer this is not necessar= y > > > > > + because values that do not fit the (smaller) target type a= re > > > > > + unspecified anyway. */ > > > > > + if (demotion && float_expr_p) > > > > > + { > > > > > + wide_int op_min_value, op_max_value; > > > > > + /* For vector form, it looks like op0 doesn't have > RANGE_INFO. > > > > > + In the future, if it is supported, changes may need to be > made > > > > > + to this part, such as checking the RANGE of each > element > > > > > + in the vector. */ > > > > > + if (!SSA_NAME_RANGE_INFO (op0) > > > > > + || !vect_get_range_info (op0, &op_min_value, > > > > &op_max_value)) > > > > > + break; > > > > > + > > > > > + if (cvt_type =3D=3D NULL_TREE > > > > > + || (wi::min_precision (op_max_value, SIGNED) > > > > > + > TYPE_PRECISION (cvt_type)) > > > > > + || (wi::min_precision (op_min_value, SIGNED) > > > > > + > TYPE_PRECISION (cvt_type))) > > > > > + continue; > > > > > + } > > > > > + > > > > > + if (vinfo !=3D NULL && slp_node !=3D NULL) > > > > > + cvt_type =3D get_vectype_for_scalar_type (vinfo, cvt_type, > slp_node); > > > > > + else > > > > > + { > > > > > + bool uns =3D TYPE_UNSIGNED (TREE_TYPE (vectype_out)) > > > > > + || TYPE_UNSIGNED (TREE_TYPE (vectype_in)); > > > > > + cvt_type =3D build_nonstandard_integer_type > > > > > + (GET_MODE_BITSIZE (cvt_mode), uns); > > > > > + cvt_type =3D build_vector_type (cvt_type, nelts); > > > > > + } > > > > > > > > So this would then become > > > > > > > > cvt_type =3D get_related_vectype_for_scalar_type > > > > (TYPE_MODE (vectype_in), cvt_type, TYPE_VECTOR_SUBPARTS > > > > (vectype_in)); > > > > > > > > > + /* This should only happened for SLP as long as loop vectoriz= er > > > > > + only supports same-sized vector. */ > > > > > + if (cvt_type =3D=3D NULL_TREE > > > > > + || maybe_ne (TYPE_VECTOR_SUBPARTS (cvt_type), nelts) > > > > > + || !supportable_convert_operation ((tree_code) *code1, > > > > > + vectype_out, > > > > > + cvt_type, &tc1) > > > > > + || !supportable_convert_operation ((tree_code) *code2, > > > > > + cvt_type, > > > > > + vectype_in, &tc2)) > > > > > + continue; > > > > > + > > > > > + found_mode =3D true; > > > > > + break; > > > > > + } > > > > > + > > > > > + if (found_mode) > > > > > + { > > > > > + (*multi_step_cvt)++; > > > > > + interm_types->safe_push (cvt_type); > > > > > + cvt_type =3D NULL_TREE; > > > > > + *code1 =3D tc1; > > > > > + *code2 =3D tc2; > > > > > + return true; > > > > > + } > > > > > + } > > > > > + interm_types->release (); > > > > > > > > Hmm, ownership of interm_types is somewhat unclear here - the > > > > caller should release it, or is the situation that the caller is co= nfused by > stray elements in it? > > In > > > > that case I'd suggest to instead do interm_types->truncate (0). > > > > > > > > > > It's my fault, I just imitate > > > supportable_narrowing/widening_operation, > > > I think for this function, interm_types->release() is not needed.