From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id A8E1D3858D32 for ; Mon, 8 May 2023 07:37:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A8E1D3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 4975C21AC0; Mon, 8 May 2023 07:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1683531451; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=16lW+jgidBPirGoqUXHWD5iyE/8d+tZRr0+zXqw5+iI=; b=lDoukE6E3TDMzjetcO0Ti4f2QmDTBE/1eJ9DmkfEt9/MFmO5Gvo4ym1u+9kJjlTF/j2PeK gvafGS4Gt08g6yOAbceDH8BeK4htnuQCCxFoCl3/Qh2JxsAjtHVNpIi9u82E2QRhDAfBiY dSQ3yCVd8bCz8OSGszJGEpxi0ekgxTQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1683531451; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=16lW+jgidBPirGoqUXHWD5iyE/8d+tZRr0+zXqw5+iI=; b=SqXirv03UaUapL1xXlWGB/FapwQZcYIK47StYvamTbizWh/LfkAXRtTUZioSJ8HKWA30kt aZoEQX/1jP+WK+Aw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id EDBFF2C141; Mon, 8 May 2023 07:37:30 +0000 (UTC) Date: Mon, 8 May 2023 07:37:30 +0000 (UTC) From: Richard Biener To: "Li, Pan2" cc: Jeff Law , Kito Cheng , "juzhe.zhong@rivai.ai" , "richard.sandiford" , gcc-patches , palmer , jakub Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit In-Reply-To: Message-ID: References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <436847c8-0c15-24de-5925-f56d78caf540@gmail.com> User-Agent: Alpine 2.22 (LSU 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,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: On Mon, 8 May 2023, Li, Pan2 wrote: > return !dv || (int) GET_CODE ((rtx) dv) != (int) VALUE; } is able to fix > this ICE after mode bits change. Can you check which bits this will inspect when 'dv' is a tree after your patch? VALUE is 1 and would map to IDENTIFIER_NODE on the tree side when there was a 1:1 overlap. I think for all cases but struct loc_exp_dep we could find a bit to record wheter we deal with a VALUE or a decl, but for loc_exp_dep it's going to 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 conversion isn't what we want. An alternative "solution" might be to also shrink tree_code when we shrink rtx_code and keep the 1:1 overlap. Richard. > I will re-trigger the memory allocate > bytes test with below changes for X86. > > rtx_def code 16 => 8 bits. > rtx_def mode 8 => 16 bits. > tree_base code unchanged. > > Pan > > -----Original Message----- > From: Li, Pan2 > Sent: Monday, May 8, 2023 2:42 PM > To: Richard Biener ; Jeff Law > Cc: Kito Cheng ; juzhe.zhong@rivai.ai; richard.sandiford ; gcc-patches ; palmer ; jakub > Subject: RE: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit > > Oops. Actually I am patching a version as you mentioned like storage allocation. Thank you Richard, will try your suggestion and keep you posted. > > Pan > > -----Original Message----- > From: Richard Biener > Sent: Monday, May 8, 2023 2:30 PM > To: Jeff Law > Cc: Li, Pan2 ; Kito Cheng ; juzhe.zhong@rivai.ai; richard.sandiford ; gcc-patches ; palmer ; jakub > Subject: Re: [PATCH] machine_mode type size: Extend enum size from 8-bit to 16-bit > > On Sun, 7 May 2023, Jeff Law wrote: > > > > > > > On 5/6/23 19:55, Li, Pan2 wrote: > > > It looks like we cannot simply swap the code and mode in 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. > > > > > > rtx_def code 16 => 8 bits. > > > rtx_def mode 8 => 16 bits. > > > > > > static inline decl_or_value > > > dv_from_value (rtx value) > > > { > > > decl_or_value dv; > > > dv = value; > > > gcc_checking_assert (dv_is_value_p (dv)); <= ICE > > > return dv; > > Ugh. We really just need to fix this code. It assumes particular > > structure layouts and that's just wrong/dumb. > > Well, it's a neat trick ... we just need to adjust it to > > static inline bool > dv_is_decl_p (decl_or_value dv) > { > return !dv || (int) GET_CODE ((rtx) dv) != (int) VALUE; } > > I think (and hope for the 'decl' case the bits inspected are never 'VALUE'). Of course the above stinks from a TBAA perspective ... > > Any "real" fix would require allocating storage for a discriminator and thus hurt the resource constrained var-tracking a lot. > > Richard. > -- 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)