From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id DD1443858403 for ; Thu, 18 Jan 2024 12:17:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD1443858403 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org DD1443858403 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705580271; cv=none; b=Mz5PBgv5boray2MNjh//9co1ghHWNNvk5Obdkv9eSIpXMk9Z62g2OY1C/Q0cB4VluwLJwqwFhrIGXT92RPvFHbY5WP2cSjBNJd1ZI/GKnFrx52IdpffklnnB14M7H3IzkLDNB8in78YifPLFBWSmOfGTZY/9QvEfUHMePO04eKU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705580271; c=relaxed/simple; bh=2ac/IcPNXPEvVCgt8QYIz/mkkjQZlzh4qgcvU3oDi/E=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=JQFaNefZh+0gxHf+xYld5FbqqLQtSzu4Kxfsj2Gi7zu0PnlBvyMe12XPwnz4UfIJd3kOOicy1snedNKZ8UKPMx1S6dR+4VTeB+81+sxgHDPJJSX28Rxc1ev7InyVgzK0wre+hqSQsCdnnuj38g8SI/2E1OttPb601n2pPvYP3ZY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.168.4.150] (unknown [10.168.4.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E69D81FCF8; Thu, 18 Jan 2024 12:17:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1705580268; 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=cWlXCIFBpR+I1l3S44oYsPvzttMIFqwAgKc5b9GnCPA=; b=gpU0n88KGftawXBSW1+Gh7mzW1O2G4dzX/xpsoIb+ODQ4cKRdYdOae2ShBeJzelB3f2k1U CkwzCG1ELKfjDEvScafydsRDPJ7MIvQaW4gi3++ASuCF+NyC+eEVSzeDE7sFGuJyffFFyA RKbgW1Ed1LIJj94Qm0/+MTMVQf6xyY0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1705580268; 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=cWlXCIFBpR+I1l3S44oYsPvzttMIFqwAgKc5b9GnCPA=; b=vwQyQdbYN7R4CrbuaV1FV24vT4RZkDmQnurKldb8eGxTYIPTKMJyWyOAA5W1XTVmuZ51M5 Fr6jwWhffLPnh9DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1705580266; 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=cWlXCIFBpR+I1l3S44oYsPvzttMIFqwAgKc5b9GnCPA=; b=0WgaLrY5apwwVMLpu1HmX/R2XkkiTKeNQxWt5I/3UGGQJikZvisLlbs4u8tr7iPi1LTi29 dRIjBdbWzWuj1l+eMD5eZu/LMO49b4sxXhNLIgL/Ta3LA9y1hHF16bBIkQXAvWQNxygNfw 8QvjGtxTgygpI1184Q+eLDUkhws5k4w= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1705580266; 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=cWlXCIFBpR+I1l3S44oYsPvzttMIFqwAgKc5b9GnCPA=; b=NfIZ6w7NDnXMKkx5SGz+efK/M8f8d/rcHtaENZwVxE93YS67arB4/WTTQ2YxA0eIiOHxPR grD0/85iNFCtYeBw== Date: Thu, 18 Jan 2024 13:16:45 +0100 (CET) From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] lower-bitint: Force some arrays corresponding to large/huge _BitInt SSA_NAMEs to BLKmode In-Reply-To: Message-ID: <257o685n-4254-9so7-sq07-p39s38742o33@fhfr.qr> References: <10q608oq-n50o-r767-94o0-p5o561415osr@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spam-Level: X-Spam-Score: -4.30 X-Spamd-Result: default: False [-4.30 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-0.978]; RCPT_COUNT_TWO(0.00)[2]; DBL_BLOCKED_OPENRESOLVER(0.00)[expr.cc:url]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-3.00)[100.00%] X-Spam-Status: No, score=-5.2 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 Thu, 18 Jan 2024, Jakub Jelinek wrote: > On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote: > > On Thu, 18 Jan 2024, Jakub Jelinek wrote: > > > > > Hi! > > > > > > On aarch64 the backend decides to use non-BLKmode for some arrays > > > like unsigned long[4] - OImode in that case, but the corresponding > > > BITINT_TYPEs have BLKmode (like structures containing that many limb > > > elements). This both isn't a good idea (we really want such underlying vars > > > to live in memory and access them there, rather than live in registers and > > > access their parts in there) and causes ICEs during expansion > > > (VIEW_CONVERT_EXPR from such OImode array to BLKmode BITINT_TYPE), so the > > > following patch makes sure such arrays reflect the BLKmode of BITINT_TYPEs > > > it is accessed with (if any). > > > > > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? > > > > So the issue is only manifesting during expansion? I think it would > > be better to detect the specific issue (V_C_E from register to BLKmode) > > in discover_nonconstant_array_refs_r and force the register argument > > to stack? > > That doesn't really work, tried: > --- gcc/cfgexpand.cc.jj 2024-01-16 11:45:16.159326506 +0100 > +++ gcc/cfgexpand.cc 2024-01-18 11:26:17.906447274 +0100 > @@ -6380,11 +6380,16 @@ discover_nonconstant_array_refs_r (tree > /* References of size POLY_INT_CST to a fixed-size object must go > through memory. It's more efficient to force that here than > to create temporary slots on the fly. > - RTL expansion expectes TARGET_MEM_REF to always address actual memory. */ > + RTL expansion expectes TARGET_MEM_REF to always address actual memory. > + Also, force to stack non-BLKmode vars accessed through VIEW_CONVERT_EXPR > + to BLKmode BITINT_TYPEs. */ > else if (TREE_CODE (t) == TARGET_MEM_REF > || (TREE_CODE (t) == MEM_REF > && TYPE_SIZE (TREE_TYPE (t)) > - && POLY_INT_CST_P (TYPE_SIZE (TREE_TYPE (t))))) > + && POLY_INT_CST_P (TYPE_SIZE (TREE_TYPE (t)))) > + || (TREE_CODE (t) == VIEW_CONVERT_EXPR > + && TREE_CODE (TREE_TYPE (t)) == BITINT_TYPE > + && TYPE_MODE (TREE_TYPE (t)) == BLKmode)) > { > tree base = get_base_address (t); > if (base > This doesn't actually do anything, because the base is TREE_ADDRESSABLE. > The var gets both with -O0 and -O2 DECL_RTL like > (mem/c:OI (plus:DI (reg/f:DI 95 virtual-stack-vars) > (const_int -64 [0xffffffffffffffc0])) [2 bitint.2+0 S32 A128]) But then it's not promoted to register but instead somebody decides it gets an integer mode instead of BLKmode. > but the problem is that the expansion of the VAR_DECL because of the > non-BLKmode is forced into a pseudo. > --- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100 > +++ gcc/expr.cc 2024-01-18 11:56:07.142361031 +0100 > @@ -12382,6 +12382,17 @@ expand_expr_real_1 (tree exp, rtx target > } > } There's already an odd bit of code dealing with non-BLKmode to BLKmode converts, suggesting those would need intermediate memory, but likely not triggering because the base is a decl, not a handled_component. Does it work to go there also for DECL_P (treeop0)? > + /* Ensure non-BLKmode array VAR_DECLs VCEd to BLKmode BITINT_TYPE > + aren't promoted to registers. */ > + if (op0 == NULL_RTX > + && mode == BLKmode > + && TREE_CODE (type) == BITINT_TYPE > + && modifier == EXPAND_NORMAL > + && VAR_P (treeop0) > + && DECL_MODE (treeop0) != BLKmode) > + op0 = expand_expr_real (treeop0, NULL_RTX, VOIDmode, EXPAND_MEMORY, > + NULL, inner_reference_p); > + > if (!op0) > op0 = expand_expr_real (treeop0, NULL_RTX, VOIDmode, modifier, > NULL, inner_reference_p); > doesn't work either, while we get the MEM op0 in that case, because > mode != GET_MODE (op0) we still take the > /* If the output type is a bit-field type, do an extraction. */ > else if (reduce_bit_field) > return extract_bit_field (op0, TYPE_PRECISION (type), 0, > TYPE_UNSIGNED (type), NULL_RTX, > mode, mode, false, NULL); > path which can't deal with BLKmode extraction from non-BLKmode. > I guess we could in the above new expr.cc hunk perhaps > also if (MEM_P (op0)) op0 = adjust_address (op0, BLKmode, 0); Hmm, 'reduce_bit_field' is odd with V_C_E - if you disable that, does it work? How does it behave differently when the base is BLKmode instead of OImode? Richard.