From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 5C8C03858D32 for ; Mon, 8 May 2023 06:29:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C8C03858D32 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-out2.suse.de (Postfix) with ESMTP id EDCFE1FD9F; Mon, 8 May 2023 06:29:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1683527381; 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=jt1qpCoMgZNoioyc/P4RwpoO5CkB9hbt844v2bSemWE=; b=OIk3maO3l25miu1pcqetFW7coiScpcM8T5ey+buO0IIp0nz1C10ClNlGqx6NE83kED7PoA 5UHCXXzz+y4sbU1mT4FJLruafavoSLyuF66SIfzZT/1BrT+CTG6ZrxLR8F/f/w/NlGfKGR eMYZ282qkR35wXLjvxLR78H3YydDeWE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1683527381; 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=jt1qpCoMgZNoioyc/P4RwpoO5CkB9hbt844v2bSemWE=; b=0jpHwRCZpnHE9kvAVvnN3FA7ED75A5ij1oDMldGvDrZcAyT7aRjclkr3kqzIUyP65sf/KS L8RHyMMKIPHRDwBg== 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 8AB802C141; Mon, 8 May 2023 06:29:41 +0000 (UTC) Date: Mon, 8 May 2023 06:29:41 +0000 (UTC) From: Richard Biener 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 In-Reply-To: <436847c8-0c15-24de-5925-f56d78caf540@gmail.com> Message-ID: References: <20230410144808.324346-1-juzhe.zhong@rivai.ai> <2978624D57874251+2023041307225185723242@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 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.