From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.115]) by sourceware.org (Postfix) with ESMTPS id 69FD13858C31 for ; Fri, 25 Aug 2023 12:44:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 69FD13858C31 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692967488; x=1724503488; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gWxNk2tJLvktFWQz1aVvOeBi3J5DoYxgdVfQ5iNIjk8=; b=kZEnLMU2MYTVnZEA5TGiJutKD0a3XH2zgG6ijVm4TlQ2N8q/sBo8IjXS Rk6M2bTtRU+AN20py2yxTdXKLV+3fkZ7RrEvZWX4PaCwaNqswH+76yAcI e4wuacUHSdThfYpkBmYid4P3zvtFMzNAYgIfWt0X7Va9rJ2ILoHAsVrs1 kXuSbGHrrFxRlJlu2DtK2jZOYNho+4brn9z33YrAzpRijvJbaEr3DDWeq /vRKSh/MBEWgi5wfFSXkG5Z7oPLlZjJ6empFFDydeDR6j5SkhXBDl8xdu 1XuL1wFOOvPZU0SaXYqcts0TN9grCEi3pHyXirdYAlm1/188CYpMjEBQK w==; X-IronPort-AV: E=McAfee;i="6600,9927,10813"; a="374679424" X-IronPort-AV: E=Sophos;i="6.02,195,1688454000"; d="scan'208";a="374679424" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Aug 2023 05:44:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10813"; a="802951264" X-IronPort-AV: E=Sophos;i="6.02,195,1688454000"; d="scan'208";a="802951264" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga008.fm.intel.com with ESMTP; 25 Aug 2023 05:44:46 -0700 Received: from fmsmsx602.amr.corp.intel.com (10.18.126.82) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Fri, 25 Aug 2023 05:44:46 -0700 Received: from fmsedg602.ED.cps.intel.com (10.1.192.136) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27 via Frontend Transport; Fri, 25 Aug 2023 05:44:46 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.173) by edgegateway.intel.com (192.55.55.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.27; Fri, 25 Aug 2023 05:44:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mcBuaPJtcWIWdzq6GVIEThGmQUHMiynKRQyy6k/rMnZpZniJO8MjgL7c71pkrDwiZt7HGnPBrRsNrbQWM1N+RROuP34yS0QwmPuKYkijJoVVsAMxmXGqW1xiYrtoNw7s6bgJBv5R2r92GPFQF/z64trGpMJYqZZFfGT4Qxqi1zeTSGZaGT0Qvz8ds7+5p1m+O/lRqoyQqaOSis1rNErvcyT/He54sflKBEPntbrlVd/cptdLErkyqsWu7taubuyzWbn5cxtSMDut4h2r/VNFof8w9pUq2aWK5/nVEw7FKFUCCFxdHNhy8L4YbkD90E4wUszJlLxcY/rT3BV8qr37gQ== 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=nqmPYlfF10Sm7xHuzIQk6MkHBmawdiz0XXhg4jslnQE=; b=l7eCEFb40KtimGINO3JNYDf6VlcAoNdInkJZjYxjouLjsS5GiJsrjz7nsFOsKhRLCsyGsewHbDd5zrIj5tHduDczJ1NzAKcXnKo7xQX/KN9dNq5vzQsxLHnEk5wYqKZCscHE8opBnICDG8kdNObL+uGoyG7GhaKTRBJqgsANTjSdLUNafGt0Sj6naDlT5o0CebQt/LxjKCoVhQ1nQJ63QYJ0XGMMGozskCZJp8k5llZPWXks26S2zzGSG4VSAkXXMkS6HsfAPszpQ/KZ1u0sSEvenYTKgubNj8d1AIofHDqdqT2htU5xhz9/yKgEAZOIjZTPVTMor/IyZBggLrUiDQ== 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 MW5PR11MB5908.namprd11.prod.outlook.com (2603:10b6:303:194::10) by IA1PR11MB6074.namprd11.prod.outlook.com (2603:10b6:208:3d6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.27; Fri, 25 Aug 2023 12:44:42 +0000 Received: from MW5PR11MB5908.namprd11.prod.outlook.com ([fe80::6ff9:5a3d:4981:3476]) by MW5PR11MB5908.namprd11.prod.outlook.com ([fe80::6ff9:5a3d:4981:3476%5]) with mapi id 15.20.6699.027; Fri, 25 Aug 2023 12:44:42 +0000 From: "Li, Pan2" To: "Li, Pan2" , Jeff Law , "gcc-patches@gcc.gnu.org" CC: "juzhe.zhong@rivai.ai" , "Wang, Yanzhang" , "kito.cheng@gmail.com" Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook Thread-Topic: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook Thread-Index: AQHZ1ADYxKbsV+kXtUGNddvPCFujsq/0zlaAgAJsLPCAALjDgIAABR4QgACSNQCAAFof0IACEI2A Date: Fri, 25 Aug 2023 12:44:42 +0000 Message-ID: References: <20230821072627.3984748-1-pan2.li@intel.com> <995842b2-2765-24d5-466e-4588dcdcc48e@gmail.com> <951fced9-f798-f9b6-7827-14447a93d1c9@gmail.com> 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: MW5PR11MB5908:EE_|IA1PR11MB6074:EE_ x-ms-office365-filtering-correlation-id: 2f851962-938a-49fa-d5c7-08dba5690dc4 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xfKNcsmPWqJHZQa5zrDQXdTrxYgR8CSKJ2oX0/M4s/ZqmYQOwgRmvM1Jbvey43xCVRyAzfSfwXvVqw64bbs57YcaImoxOXGzG8ctXGvhgy0s7e3GpAVEIrljoe+Iz+w5FA82XYDLzdVnFcV9QwhLP7gVXZTLyOgCU10pfDxfwQnFL9Gr5uz8quzuqLFT0zdcBCegwkT+uw1I+Qwy9MhWKmnWEeqMR0SdAjZjW5isJMxa7UeGWJCRuawAliJyglV8OIE6rrpF7Yb0ErFqtn608bMgrowwNhj+lu1HDm8hOsTgJGpDbcTBwpXhPytkR4+6QxPqxKurFO4rRRV5RJRY2Mgmnh5b9G+LAl/P05ujvEQXPfOLmtxfcDiAODJSQ4nIrSSf9Fn3GxsIYJcf3Sz3vnTBPqVE2GrxIaG4u1YFhPRNhIcNt3jG2yoyvet2yR1VyHxCOdFm2LvgHsq4htbanss5ileFukh3/Ygqgg+/TzOlR72/2sdRXdNa1HcsreNIdF4P9Z0gb2gYTOv7fmmBrOfpkTnt0aQyXc7S3uW+w6lcDydugnF3bAbm8pckoiJqzwNVGJbKu3wYrU8I46Ks30FNJsFL5xAMQivRRZ6a/ko= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW5PR11MB5908.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(136003)(396003)(376002)(39860400002)(366004)(346002)(451199024)(1800799009)(186009)(84970400001)(122000001)(86362001)(33656002)(38070700005)(82960400001)(38100700002)(6506007)(71200400001)(7696005)(478600001)(52536014)(5660300002)(76116006)(54906003)(110136005)(4326008)(8676002)(8936002)(64756008)(55016003)(316002)(83380400001)(9686003)(53546011)(26005)(66946007)(41300700001)(2906002)(66446008)(66476007)(66556008);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ggbRc68KtmCS4jMlNl7EtAU3ADMaAMqmBy17AFGOZUreg3FUEDSfBgxuw1eX?= =?us-ascii?Q?fDOiAbFjebh8kPB0Ja8gGo3egdzGkPe6IXwpAECPKTKj3X3eEtz0YqcSreYy?= =?us-ascii?Q?W0dZES0N3605GbNDEJzjNLmcGpMbM6kNrCCrKKFQ2f64K7xk2uAAXkpXjrn/?= =?us-ascii?Q?PduoChQeutyppfAUpfFsW/qrWw9LaGd1B5234JNg5aX0713fdSOKckcxtknH?= =?us-ascii?Q?m5nCUXZQ+QoG6LFIYDqx2iXNANR+H7bsonMdjfIW7zDNnpIJ38w4MHXcw09c?= =?us-ascii?Q?Yq3WyOwXOBoqmHF9wqtgagYcoQNmBUA6DJFYxqBlcGmBGPn1zRZNfvmByRh8?= =?us-ascii?Q?G0coeM4agfKsAviAM/vsvLHjo4KH/xNGrQb3ITwk1T3qDFjEET5AJMAnXJh/?= =?us-ascii?Q?foRgWJCDYKem2Zl/bG/0z2sE+3fe/7DApeHqRVdu6aJYyejvfgHr/xfLCXD3?= =?us-ascii?Q?OZYIJcMu6iEY3sDtdjQNY+0ElAJAH+YDlCGZN2BugJ8SjD9G+UuSHRI5xJf6?= =?us-ascii?Q?HNQoC+zWxCiNeaeDU/dg5WnxHlEkv+M51As6vCS1dAWzh+eH45ym6NrO6w7v?= =?us-ascii?Q?pQvCbsBfiWyz4BA5V4FbMsx5DSiVjFGk/QdVa4PEMlat3nY0BCvChUe5++0i?= =?us-ascii?Q?RAasPDmKilJwjUQtJv5n6EW+34Xoa0QIzjkfh6+GGGO5gpWtbiipuEqJK9ly?= =?us-ascii?Q?oeT9GrSO2FZRWcSf40cveSuEiuGwe8SJP1Jd5VMrBizVb6LDDVJVEn5qcv7Q?= =?us-ascii?Q?ZcLEv0wAb+Q96CMIdNoYvf3UYOgFq/tKy61cK895CWW7V5b59gfM3SSEWbW0?= =?us-ascii?Q?2tJ3CiqXEeuLNxiJy1r2vWt3f8dj8KIw9jnZFsLUgWAoiaacCX7qeTTt8xnZ?= =?us-ascii?Q?kBmuRJ/bkl5bBNDVdObjUy6EbEKFQa3zkkJoxsGi6RFO3yH1dPMf0BD8srXc?= =?us-ascii?Q?KGyC5UAysmhKnW+wrgeoVQn4DLBokbvHMketjschr/bEcjkYB7CLORkF79pL?= =?us-ascii?Q?va3y5nveOAu6V3bGgj45WPADsSmDv8p6s1UXY27/bZULwQyBZjEf5T5J0Fqb?= =?us-ascii?Q?k0j0xEHZDpU4MJeK03judtKNKwb05NnUB9uVyUEQ2dJDF4rqNnwSxlWIolst?= =?us-ascii?Q?XjMQ8qOzlfYj79QwL66GfyrGTzp4XbfAbF11rjuO4pX9z0QGTYycY5IIcEcP?= =?us-ascii?Q?mJxXyJ0/Gv4vzFMj+cH/zSKjEqcUOJsjySfp8nYa4wS0l5DrzJ67IW2rq4n9?= =?us-ascii?Q?faIqqfYI/IAM7tT0KOvJS3oIMsJVGuLp9UEI1QEmSqTeZ/3Dpb+nbZm99YYN?= =?us-ascii?Q?VtdjsGBMv41carQQiWWoMTb9tLy75RgG6Bvw91A8D56QOF65aQ4+9lYgNH6E?= =?us-ascii?Q?kpAStl/etJKy5/wL9NqKXufYx+nAOtnSfSDOMeiktWjbkRFeZ9gY6S3dJIix?= =?us-ascii?Q?iEHmRFWAONZAsEt1xP9onEGlZZfWKJyRxUT+lZJYKamw9Ij8c2UvGEXlGZ3O?= =?us-ascii?Q?TN5JPzMjL+mAAzG7wYd2YcdgMvjxp6Xd8B4yI4MUm8zi8Avatw3Amyio1f9e?= =?us-ascii?Q?UngITpRhZclRebJavt0=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: MW5PR11MB5908.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f851962-938a-49fa-d5c7-08dba5690dc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2023 12:44:42.3681 (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: iz4UN93heJWdEnPYcf64FDrVmCjVKc9L9niF3BSG+nKqf2beH1Z8S6+ezSQuDN1O3wJvKV7I2lvz5sQa3erakA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB6074 X-OriginatorOrg: intel.com X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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: Hi Jeff, > You might also peek at the RTL gcse/pre code which is also LCM based and= =20 > has the same class of problems. I found a similar approach to take care of this in gcse.cc/pre_edge_insert = with some comments as below. /* We can't insert anything on an abnormal and critical edge, so we insert the insn at the end of the previous block. There are several alternatives detailed in Morgans book P277 (sec 10.5) for handling this situation. This one is easiest for now. */ if (eg->flags & EDGE_ABNORMAL) insert_insn_end_basic_block (index_map[j], bb); else { insn =3D process_insert_insn (index_map[j]); insert_insn_on_edge (insn, eg); } It looks the insert_insn_end_basic_block is designed to handle the ABNORMAL= edge by inserting at end of previous block from the comments. Pan -----Original Message----- From: Gcc-patches On = Behalf Of Li, Pan2 via Gcc-patches Sent: Thursday, August 24, 2023 12:54 PM To: Jeff Law ; gcc-patches@gcc.gnu.org Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang ; kito.ch= eng@gmail.com Subject: RE: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook Thanks Jeff. > That implies a save/restore pair around the call (possibly optimized so=20 > that we minimize the number of save/restores). I would have expected=20 > x86 to already be doing this. But maybe there's some ABI thing around=20 > mmx vs x86 state that allows it to be avoided.... Very similar to save/restore but optional. If no static rounding mode instrinsic here, it is unnecessary to add save/r= estore pair around the call. I bet mode-switching take care of this already. Pan -----Original Message----- From: Jeff Law =20 Sent: Thursday, August 24, 2023 7:27 AM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zhong@rivai.ai; Wang, Yanzhang ; kito.ch= eng@gmail.com Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook On 8/23/23 08:54, Li, Pan2 wrote: > Thanks Jeff for comments. >=20 >> Understood. So the natural question is why does x86/sh not need this >> for its mode switching? Don't all the same issues exist on those >> targets as well? >=20 > AFAIK, it comes from the different design principle between the risc-v an= d x86/arm intrinsic API. > The risc-v rvv FP rounding mode intrinsic API has one abstract level abov= e the insn itself, while > the x86/arm only indicates the semantics of the insn. >=20 > For example, if one vector instruction VFADD doesn't have static rounding= mode (aka encoding rm in insn), > there is no such a intrinsic API contains rounding mode argument in x86/a= rm. While the risc-v fp > vector intrinsic will always have static rounding mode API if the frm is = honored. >=20 > In short, the risc-v intrinsic API is closer to the end-user, while the x= 86/arm instrinsic API is closer to insn itself. OK, but I'm still strugging to see how the distinction is important=20 here. Ultimately there's a state at a call site. We need to make sure=20 that state from the current function doesn't impact the callee and we=20 need to make sure that the callee doesn't impact the state in the caller. That implies a save/restore pair around the call (possibly optimized so=20 that we minimize the number of save/restores). I would have expected=20 x86 to already be doing this. But maybe there's some ABI thing around=20 mmx vs x86 state that allows it to be avoided.... >=20 > For the rest part, will have a try based on your suggestion soon as I am = in the middle of something. No problem. Get to it when you can. I think it affects you more than=20 me :-) jeff