From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by sourceware.org (Postfix) with ESMTPS id A467D3858D37 for ; Tue, 9 May 2023 11:50:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A467D3858D37 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=1683633050; x=1715169050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WtbYUtF9xu2k7DPXPZwZP3+6fIAV53mLCyVTAcyf+Zk=; b=Mftzmev8D0usK8sNJg/uNEmOQ3E0XuOeZZTIpMzahhvNzPgvS3x1oN0+ 7VZ0aoRx9mpP5ka+ZumMqe7VC6HG8KGnFe4xXyS9hu/Is3tmrbWVjiAjQ wUnNMirKB4iapvPZYOhrLGwDiO67mZ/s8EPg7bkTtMaWD/OFtBm+LpJ1c h3kS8yLAdlKFc99Vo248IX5n3zdmrXsMmtG6ZtBNb11U0md6QhAoKJT2r x2BK/X9Fpd23fpqJkF0Yer6ssxjIHAdboo13I5yigPoIjO/OHLbPRtHUl q4TRUhsO4gNXhS42bpLbHHs3+30iyXxtsS43GcMowYtZcCpt6ZqU0TT7/ Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10704"; a="334356326" X-IronPort-AV: E=Sophos;i="5.99,262,1677571200"; d="scan'208";a="334356326" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 May 2023 04:50:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10704"; a="843072414" X-IronPort-AV: E=Sophos;i="5.99,262,1677571200"; d="scan'208";a="843072414" Received: from fmsmsx603.amr.corp.intel.com ([10.18.126.83]) by fmsmga001.fm.intel.com with ESMTP; 09 May 2023 04:50:49 -0700 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) by fmsmsx603.amr.corp.intel.com (10.18.126.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 9 May 2023 04:50:49 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 9 May 2023 04:50:48 -0700 Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23 via Frontend Transport; Tue, 9 May 2023 04:50:48 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.57.43) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.23; Tue, 9 May 2023 04:50:48 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I0ZvmuzXU+zEQ1kUJdlC5WRY8xb24iY7LSzUhOnnSyqlKbzc8GihH8kTEHbYzXRWhJsx79xbPXVaZXv8snBzTIPb0O/ayB6HEXtopLNwiDe6Yu4WAWXYtd/iJ1K/2fkXMhWaE4KFdgv9HYtIUSPqlkiJIVSboYRCCR8vSPQXwrRjEy1rQRpSQUsIOwRzbB+Le9oDj/cQLtmyo8wy9lamYs9+6Kvw4u0PYMfcLUV+OyiDyRFnlBWp6JSpOJ9phjnmQWcSeVhUkxtKs8jn6FpNopdfKa8zdJFnJ3FwSHD4m47Eu6kP0PwDXko44R/78WeQHT9y7DG3hCetyBTtbSE5qA== 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=LOs/CMiHjcHQ9TVUKzDV/luiHJZ9G1VfYQhV80zFxqQ=; b=BvB1enF3Xdl4grKIa7zA1fa0Zf889mnuNivKnC/Nc93/n7s/TmqNlw7Ckt9E8FSFsYlxaUHWl1BQbHm4mMWvBpQW4OsfbcLchF8HHAJe1/MDkabyP2WJBprr1rbXyOXSmluU9HS0gHz9hnVxSgDzVBiNMmjv4UL8pzg/3xmrZQIfsvSzaF+eLXelqD+t2vGUqtT+PdpRdm62vDWAUXfHoCdD9KnBI+9QSIgzCw6JMAhKGaOU4ZCS6PbuYQ7J58R4kmBuhYiJnzAXQZZO6pvj1o9by7T/0/DSmYfTJwVV9dvXrZQd7J6WxN1tt9BNgHCuREd8Lvq7vT0pDE/gHwCmIw== 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 BY1PR11MB8077.namprd11.prod.outlook.com (2603:10b6:a03:527::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6387.18; Tue, 9 May 2023 11:50:46 +0000 Received: from MW5PR11MB5908.namprd11.prod.outlook.com ([fe80::bbc5:f013:1f53:10a9]) by MW5PR11MB5908.namprd11.prod.outlook.com ([fe80::bbc5:f013:1f53:10a9%3]) with mapi id 15.20.6363.033; Tue, 9 May 2023 11:50:46 +0000 From: "Li, Pan2" To: Richard Biener , Richard Sandiford CC: Jeff Law , Kito Cheng , "juzhe.zhong@rivai.ai" , gcc-patches , palmer , jakub Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit Thread-Topic: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit Thread-Index: AQHZgPgLEItqgvjuhkOVhtsYc5zgaq9P6wCAgAABRvCAAATiIIAADMsAgAADbfCAAbvJTIAAAjSAgAAXbvA= Date: Tue, 9 May 2023 11:50:46 +0000 Message-ID: References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <436847c8-0c15-24de-5925-f56d78caf540@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_|BY1PR11MB8077:EE_ x-ms-office365-filtering-correlation-id: dfe65ac4-b95e-410b-0fda-08db5083a06c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mGU3ZK/Vf4sQ+FspGnkWMHVHH7lwKfu1s28nppPjbGWjJYKZavTMiWBaiWTGmjjLuZIGbr7I0W34WGvOkvloQwhZ8kqHWm6ViidiAFh7sexJZnB2KxnNp1EwhMFWwOkPoRiLARc7c2SWRBrjUTeX6m/NMOgdHZfFzaXwtm4nlukzhfkzxEql3aT8SOuM3m7y71e9Jt8wswBpw3gKMp7LM6JnHTflS9HqMVWt7A06GOO+3Xzu+XLIgKHETMJV1YjMzqIHrZGa9ew9M4/kYRTYaZoi8vgugZEmkDGhc2NqfKkvtAcDcRGF25tG4TFiy9ihx/Ysi/vyY2Gu+qlSpdzCSe6nlK3dikhxM9OQNWUNUlYR0rtDzevAFYuc+ObBX/MEDCiTyzpapGWnoW+8XtvxpvxSzhanlz8goPuiB+wTMltgqjo63XcTPuFWuU8WNsj3L1T5cVi2bYW7/fRgWjAoMUoTB1b4wXv/7a3mTUUZvgIrkFZmON7nUfUmW08byOf4fRLZQ5fnYrEaSbB00NJmm+Yzr+YaBfQFMmZ3+ke2Xpu/rN+syqwvTtsADRQpREKr06O2Q8HxsNzpziR75gO51e1YrAMx5wOQGJ/x3rQiSWuKEaXF4tPwTvFELwwO1lu8 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:(13230028)(136003)(346002)(376002)(366004)(39860400002)(396003)(451199021)(7696005)(26005)(41300700001)(86362001)(38100700002)(55016003)(71200400001)(82960400001)(83380400001)(33656002)(186003)(6506007)(53546011)(9686003)(66899021)(122000001)(64756008)(66476007)(66556008)(66946007)(66446008)(76116006)(54906003)(38070700005)(110136005)(478600001)(4326008)(52536014)(8936002)(316002)(2906002)(8676002)(5660300002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?n4soeeOmPS7X35DCFIeYtAZWYPZJRZmVxWDNH0uutHerEBto6HiKb9jls8Bm?= =?us-ascii?Q?t7HUWSI+IntE+n+B4sFWZLjjV2qUwE64D7yn2XI432b14ZbVdJGPsemipES3?= =?us-ascii?Q?9GZmnztiXcehxTbhWKD9t4z5pxwtywIMzKx3Tv5mjVSvpF7hYwXV7gK/qpcy?= =?us-ascii?Q?+NZbQdrlORxJykAgMvV6FZmlCgeibTDEvgRuIvRG6JDSUkT31m++LaqAoGZM?= =?us-ascii?Q?i92Xn3M7oGGr5xQpFhF+LyJSzIuI+fbsKoTLP1wKmt1+tNc/aRM4cFbGG5YS?= =?us-ascii?Q?BC7Broeb8aiBgPzIJayW29D2TSTtrBSy5GBMl8kHc4jjw8j1SQZmM62f8n3M?= =?us-ascii?Q?TpKmQbqe8sMfezlEMx5Xi9rMSQp5JagjQ7hgCUPtMRi2lCc+oVIdHChR3vGv?= =?us-ascii?Q?Eb2VqMjpEpFLFe2nKlbhGoNzQJRPlEcgOwhF55xIuaVBEinOhERxTeWOTZNo?= =?us-ascii?Q?I5Cr7aUBIP3Kz2OrggiW5vtevBdaU7ddM8ugqkylTET114zTHNmexqaNwYZj?= =?us-ascii?Q?6dzC9psfZC4SoCRp+oc+WHgZ+ihdCe319qjIiXCtdSF/Uf+6nL+qHPh8ep8m?= =?us-ascii?Q?MhBqbT3HKkvwonZXwHI9yXf2xdLve+KF8HCg0wQb2aUcUKgq8WwCVadNvtmB?= =?us-ascii?Q?hriTnJBNyH0ZaS2sj5VDFwdMwvX+EK86OC/HYI2mkeuwnHs7b/fvh8WtjE/Z?= =?us-ascii?Q?uSSSgdPXEFg9lchjZq4rPttjM+6HnFT2hAv8Tjs4nK1D2zYc0KA+l4mZaDxg?= =?us-ascii?Q?mIGkx0vClkYcQk/27OHDRRUv+J5mYcBEf8NAnJHtgrkXAdqA4kYL10lZxVno?= =?us-ascii?Q?i/282NUdDA3b7qRc2vw/AxW5luCIF4c6OllIuWGGsGyOMCT4YzcwkvyR4NEd?= =?us-ascii?Q?LBBgMEilK4rJNGEccnfYfn3D0+baFNYkEjYYVngBoZ4PeOAXkUOKGlYI3wcV?= =?us-ascii?Q?xm3uUtb9BNtqjpY4nDiip2NfqJirVwrs/WLeUxhPB5KTmqUBF6juOG/nj3Q7?= =?us-ascii?Q?7YEwBTsMXBX9SUMwnW29URCaftxgCTsKRvUkGRwae64URBn+4tVpkKK0xVRg?= =?us-ascii?Q?aWaePWSFkez8UZmPh3dRTMVYuheARL0vY1ZA85tl0ly626Io0cgh5BG6bxe5?= =?us-ascii?Q?uTQcgx/h2TpS/Eiyk2n84K9fjaFsuOVympHr2EZAmnA33uTo6E4gumrMXuTs?= =?us-ascii?Q?oD/tWrSQm1O1I5WLygmHB6/FWhLvFtXatK7hfMfXznzIybnoZd263uk5xfkq?= =?us-ascii?Q?HU9vvJDENRO0yQE65bSEjbr8n4N9xe/fk4zDauYsbtfNOlUFnwC7EKL1SDxU?= =?us-ascii?Q?9WvEaz/eCTLzsrHVtbzYQaLjF866W2QwNutkgqU26I/iBw5tu1mvBZaMj8ME?= =?us-ascii?Q?tZC/wh/YOr9/7Pg/CbWuM1WlBz5Jopa4UZ4ozSnKaLyIAzz//gEdPA2kYima?= =?us-ascii?Q?1bJ6DIOY1GEPqdgM5aN8ZxaRvKokE/MSw331js10x1/DCoKglui/DqXnAkb0?= =?us-ascii?Q?GvpQJIUDsrmYQ35gYxB64KLvUb2CSq9Gk0qC/CqPzljS4KPYhaSbgNA4dYhU?= =?us-ascii?Q?YMkTb3j0ZJCMJhJwMPU=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: dfe65ac4-b95e-410b-0fda-08db5083a06c X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2023 11:50:46.5013 (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: IhI46J7IZOBNz86YDvT+wvOBbG+IfC0cgW+SvsUzygGNoGUdtxlBXTWt4U7SUKyCGNCxbi6MFQeRkRlyCEpDFw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR11MB8077 X-OriginatorOrg: intel.com X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_NONE,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: Sure thing, I will have a try and keep you posted. Pan -----Original Message----- From: Richard Biener =20 Sent: Tuesday, May 9, 2023 6:26 PM To: Richard Sandiford Cc: Li, Pan2 ; Jeff Law ; Kito Ch= eng ; juzhe.zhong@rivai.ai; gcc-patches ; palmer ; jakub Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to= 16-bit On Tue, 9 May 2023, Richard Sandiford wrote: > "Li, Pan2" writes: > > After the bits patch like below. > > > > rtx_def code 16 =3D> 8 bits. > > rtx_def mode 8 =3D> 16 bits. > > tree_base code unchanged. > > > > The structure layout of both the rtx_def and tree_base will be somethin= g similar as below. As I understand, the lower 8-bits of tree_base will be = inspected when 'dv' is a tree for the rtx conversion. > > > > tree_base rtx_def > > code: 16 code: 8 > > side_effects_flag: 1 mode: 16 >=20 > I think we should try hard to avoid that though. The 16-bit value=20 > should be aligned to 16 bits if at all possible. decl_or_value=20 > doesn't seem like something that should be dictating our approach here. >=20 > Perhaps we can use pointer_mux for decl_or_value instead? pointer_mux=20 > is intended to be a standands-compliant (hah!) way of switching=20 > between two pointer types in a reasonably efficient way. Ah, I wasn't aware of that - yes, that looks good to use I think. Pan, can you prepare a patch only doing such conversion of the var-tracking= decl_or_value type? Aka make it typedef pointer_mux decl_or_value; and adjust uses? Thanks, Richard. > Thanks, > Richard >=20 > > constant_flag: 1 > > addressable_flag: 1 > > volatile_flag: 1 > > readonly_flag: 1 > > asm_written_flag: 1 > > nowarning_flag: 1 > > visited: 1 > > used_flag: 1 > > nothrow_flag: 1 > > static_flag: 1 > > public_flag: 1 > > private_flag: 1 > > protected_flag: 1 > > deprecated_flag: 1 > > default_def_flag: 1 > > > > I have a try a similar approach (as below) as you mentioned, aka shrink= tree_code as 1:1 overlap to rtx_code. And completed one memory allocated b= ytes test in another email. > > > > rtx_def code 16 =3D> 12 bits. > > rtx_def mode 8 =3D> 12 bits. > > tree_base code 16 =3D> 12 bits. > > > > Pan > > > > -----Original Message----- > > From: Richard Biener > > Sent: Monday, May 8, 2023 3:38 PM > > To: Li, Pan2 > > Cc: Jeff Law ; Kito Cheng=20 > > ; juzhe.zhong@rivai.ai; richard.sandiford=20 > > ; gcc-patches ;=20 > > palmer ; jakub > > Subject: RE: [PATCH] machine_mode type size: Extend enum size from=20 > > 8-bit to 16-bit > > > > On Mon, 8 May 2023, Li, Pan2 wrote: > > > >> return !dv || (int) GET_CODE ((rtx) dv) !=3D (int) VALUE; } is able=20 > >> to fix this ICE after mode bits change. > > > > Can you check which bits this will inspect when 'dv' is a tree after yo= ur patch? VALUE is 1 and would map to IDENTIFIER_NODE on the tree side whe= n there was a 1:1 overlap. > > > > I think for all cases but struct loc_exp_dep we could find a bit to rec= ord wheter we deal with a VALUE or a decl, but for loc_exp_dep it's going t= o be difficult (unless we start to take bits from pointer representations). > > > > That said, I agree with Jeff that the code is ugly, but a simplistic co= nversion isn't what we want. > > > > An alternative "solution" might be to also shrink tree_code when we shr= ink rtx_code and keep the 1:1 overlap. > > > > Richard. > > > >> I will re-trigger the memory allocate bytes test with below changes=20 > >> for X86. > >>=20 > >> rtx_def code 16 =3D> 8 bits. > >> rtx_def mode 8 =3D> 16 bits. > >> tree_base code unchanged. > >>=20 > >> Pan > >>=20 > >> -----Original Message----- > >> From: Li, Pan2 > >> Sent: Monday, May 8, 2023 2:42 PM > >> To: Richard Biener ; Jeff Law=20 > >> > >> Cc: Kito Cheng ; juzhe.zhong@rivai.ai;=20 > >> richard.sandiford ; gcc-patches=20 > >> ; palmer ; jakub=20 > >> > >> Subject: RE: [PATCH] machine_mode type size: Extend enum size from=20 > >> 8-bit to 16-bit > >>=20 > >> Oops. Actually I am patching a version as you mentioned like storage a= llocation. Thank you Richard, will try your suggestion and keep you posted. > >>=20 > >> Pan > >>=20 > >> -----Original Message----- > >> From: Richard Biener > >> Sent: Monday, May 8, 2023 2:30 PM > >> To: Jeff Law > >> Cc: Li, Pan2 ; Kito Cheng=20 > >> ; juzhe.zhong@rivai.ai; richard.sandiford=20 > >> ; gcc-patches ;=20 > >> palmer ; jakub > >> Subject: Re: [PATCH] machine_mode type size: Extend enum size from=20 > >> 8-bit to 16-bit > >>=20 > >> On Sun, 7 May 2023, Jeff Law wrote: > >>=20 > >> >=20 > >> >=20 > >> > On 5/6/23 19:55, Li, Pan2 wrote: > >> > > It looks like we cannot simply swap the code and mode in=20 > >> > > rtx_def, the code may have to be the same bits as the tree_code in= tree_base. > >> > > Or we will meet ICE like below. > >> > >=20 > >> > > rtx_def code 16 =3D> 8 bits. > >> > > rtx_def mode 8 =3D> 16 bits. > >> > >=20 > >> > > static inline decl_or_value > >> > > dv_from_value (rtx value) > >> > > { > >> > > decl_or_value dv; > >> > > dv =3D value; > >> > > gcc_checking_assert (dv_is_value_p (dv)); <=3D ICE > >> > > return dv; > >> > Ugh. We really just need to fix this code. It assumes=20 > >> > particular structure layouts and that's just wrong/dumb. > >>=20 > >> Well, it's a neat trick ... we just need to adjust it to > >>=20 > >> static inline bool > >> dv_is_decl_p (decl_or_value dv) > >> { > >> return !dv || (int) GET_CODE ((rtx) dv) !=3D (int) VALUE; } > >>=20 > >> I think (and hope for the 'decl' case the bits inspected are never 'VA= LUE'). Of course the above stinks from a TBAA perspective ... > >>=20 > >> Any "real" fix would require allocating storage for a discriminator an= d thus hurt the resource constrained var-tracking a lot. > >>=20 > >> Richard. > >>=20 > > > > -- > > Richard Biener > > SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461=20 > > Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald,=20 > > Boudien Moerman; HRB 36809 (AG Nuernberg) >=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)