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 0F8A63858403 for ; Thu, 18 Jan 2024 12:35:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F8A63858403 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 0F8A63858403 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=1705581358; cv=none; b=TDbm/p7HRKOYCJzU65qc65Kj+Q4XINdGbDDbmroKjRdW0DjwoCVhNF5R3Uxu25dg3Mlz5T01ngBMy40rUqhqtW3trA2y421qH0p/SDZBQqhyxtlbgdEB2Z0M3h+/O/Xz8GL1DysTdxp5ucQyd5yLs6RZGYNgf6ekMDSXYHwZp3E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1705581358; c=relaxed/simple; bh=VSUa3rDQey8uoUd5wiAMipi5P/pE4vwM/MAyNWFbbfQ=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=Hx3WH2R+fyhsJLFm4x8isEx1+Sv2RmJ0LBtd4qAJC5LCfoaXbVoXo4DPiJqNCKIwzEXgY+NeaAT0QGDwdeN0c5rMLEoDTH8RCN3nDUwPfw+aAHNxGVvPQjQH0hqkV2mu6BTnvHx5KMdtJeR1hZUn6SM6Z+tMlJdWIuPQ0UX/fVU= 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 DBAB41FCEF; Thu, 18 Jan 2024 12:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1705581355; 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=xLy+OjCnjB/Qvt7CRkuQofPL0wq+0GPaFZjGIOccy5c=; b=vJ615A3sO4y8i75jx/QRwU43R5R0X5bKNkGD435Q6b0meMzqTd4ol1uFnaxdr/UDb5DnmA hGfOJjMOaFHEp0KWroLb0O9ZlhpHsZKgM1uA8cVdfDn9pHDBPp8MCMGGiJQ/7+mFnEHqwP +lDxL+zES4hcnONRPrT6LNpUnBlC7qA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1705581355; 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=xLy+OjCnjB/Qvt7CRkuQofPL0wq+0GPaFZjGIOccy5c=; b=8kwDWRneuXimzgO0rPJ/R2L1OXjV40SHJY2PscHxKxR96qF4YFbZoJM6a/gcYxcFXa8oP6 gERwLiR97WmUUxCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1705581353; 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=xLy+OjCnjB/Qvt7CRkuQofPL0wq+0GPaFZjGIOccy5c=; b=HHJfFaTSj/r3MFGoF6q9tqxZv105B2q6FEjd/m6EVWJ3Gwv0NygiG8eR8Y7T4JFOSRQNS/ 61ygPPsf9QSew0X7xdojrzT9tisNKEyL9w9BQW4NNo/QlhblodwneJ+AttXWRUAPZ41g0u kL+f9SPhqeYfpmw3Gi0S4AXO9eQ14Vk= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1705581353; 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=xLy+OjCnjB/Qvt7CRkuQofPL0wq+0GPaFZjGIOccy5c=; b=P6lud4Yp+Xn5aLSk8SQzS0YKTM81DpO2cQiJLDW4T76WjVNa+Pno/D185gBiiKmtbt+/G7 usMrqfsIkuZZi+Dw== Date: Thu, 18 Jan 2024 13:34:53 +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: <4n82q8o2-6333-4493-214o-p63so73sr049@fhfr.qr> References: <10q608oq-n50o-r767-94o0-p5o561415osr@fhfr.qr> <257o685n-4254-9so7-sq07-p39s38742o33@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spamd-Result: default: False [-0.10 / 50.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; 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:+] X-Spam-Level: X-Spam-Score: -0.10 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 01:16:45PM +0100, Richard Biener wrote: > > > 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. > > It is promoted to register, expand_expr on treeop0 in that case > sees it is OImode MEM and at least when optimize forces it into a register. > > > > 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)? > > Tried that, it doesn't do anything interesting. It can handle mostly > the case where it is say a large structure element, the structure is > BLKmode, but the element is not and then is cast to BLKmode > VIEW_CONVERT_EXPR. > > > > 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? > > Generally, we need reduce_bit_field to work as is even for _BitInt, > in most spots it results in the reduction for bit-field precision > which has to happen. > If we'd somehow disable 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); > case for mode == BLKmode, then we'd trigger the > /* As a last resort, spill op0 to memory, and reload it in a > different mode. */ > else if (!MEM_P (op0)) > { > case which would spill it again into memory and extract. That would > then not ICE, but I strongly doubt we'd be able to undo that later, > at least not the stack allocations. IMHO it is much better to keep > the stuff in memory, instead of forcing it into register and then > force it to some other memory. > > > How does it behave differently when the base is BLKmode instead > > of OImode? > > If op0 has BLKmode and mode is BLKmode too, then it triggers the > /* If the input and output modes are both the same, we are done. */ > if (mode == GET_MODE (op0)) > ; > case and doesn't run into anything else, so the result is just the MEM > with the array. Which is what the hack to set BLKmode DECL_MODE achieves > too. So - if we simply do /* If the input and output modes are both the same, we are done. */ if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0)) ; ? After all if we want BLKmode we want a MEM, and if we have one we should be done already. V_C_E isn't supposed to do any value transform. Richard.