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 E691D385782D for ; Tue, 19 Dec 2023 08:21:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E691D385782D 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 E691D385782D 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=1702974081; cv=none; b=Ggzbg9RI0Ybh6qB1iAiOVExxoq56OzNxFN14lvDfygofnxhsMs8Y2XOFrSqzBlrKFVdx1xdhBW+SrGILOpADHgEVVMeb2ZbuE0i1M+TVWMNsI989Hq2WvCpC3QfWF2ALD6js8SozydpOkFw2sLtejmxqsj8TWMBSXbON1lryAjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702974081; c=relaxed/simple; bh=w1JpvRTE4h5w0Mez2zoAEtsVhErS/7EowNzwPRlNQqk=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:Date: From:To:Subject:Message-ID:MIME-Version; b=HotuAsM1AmS7cvALNupB79G3nlQcbD6UnN96ilpFy1hIs/Wb3zIUGa/rQ6p8QuLe1ultqsAc6f/OtMg6PycUZY+nCj+Avagk6SejXuY2/UiATiS5ar7vjImgmAvUja8C6pj0xo+eK62RNacbJjwO5/WITiQ2g+outIz9wweWHvs= 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 83B581F7B5; Tue, 19 Dec 2023 08:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702974078; 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=frCAB3mjgsoXBi2ZGSC9qID+YQMKaunGazhitxCCQYg=; b=QRj+9MecnMAiOVXTKOqblfdF802wReCHNZAlZ+XQzHwzUYa/DHN42Fdmd/U4jufayn5EfL sTx93EnYwZKQfa32ooOPiKxZEW54kgRN3kP4IdN2BWKWx5SE8DGBETliTINMe7Dtq3L0b8 lEY+GtcHo7PP7uZ/arFnEZyVN4W61Vo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702974078; 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=frCAB3mjgsoXBi2ZGSC9qID+YQMKaunGazhitxCCQYg=; b=26oNC0Xk7gK2NEndSQIitKnDSFmMmFcKkeEDIOxWwScO85gqxPFftt1cU0ss8dXmW+79kE 2bu004hrvI3oB0DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1702974078; 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=frCAB3mjgsoXBi2ZGSC9qID+YQMKaunGazhitxCCQYg=; b=QRj+9MecnMAiOVXTKOqblfdF802wReCHNZAlZ+XQzHwzUYa/DHN42Fdmd/U4jufayn5EfL sTx93EnYwZKQfa32ooOPiKxZEW54kgRN3kP4IdN2BWKWx5SE8DGBETliTINMe7Dtq3L0b8 lEY+GtcHo7PP7uZ/arFnEZyVN4W61Vo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1702974078; 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=frCAB3mjgsoXBi2ZGSC9qID+YQMKaunGazhitxCCQYg=; b=26oNC0Xk7gK2NEndSQIitKnDSFmMmFcKkeEDIOxWwScO85gqxPFftt1cU0ss8dXmW+79kE 2bu004hrvI3oB0DA== Date: Tue, 19 Dec 2023 09:20:07 +0100 (CET) From: Richard Biener To: Alexandre Oliva cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] strub: use opt_for_fn during ipa In-Reply-To: Message-ID: <3q2snq2n-sn4n-0p60-56n5-55p9rp7sr16o@fhfr.qr> References: <34r50573-433n-4679-312p-271o551pq47n@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Authentication-Results: smtp-out2.suse.de; none X-Spam-Score: 1.88 X-Spamd-Result: default: False [1.88 / 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]; NEURAL_SPAM_SHORT(2.98)[0.993]; 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)[suse.de:email]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; BAYES_HAM(-0.00)[21.68%] 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 Tue, 19 Dec 2023, Alexandre Oliva wrote: > On Dec 15, 2023, Richard Biener wrote: > > > You have to be generally careful when working within IPA > > with function bodies without push/pop_cfun around that, several APIs > > have variants with struct function sepcified, using the wrong one > > will get you a NULL cfun which _some_ of them handle gracefully and > > "wrong", all EH stuff is amongst this for example. > > *nod*, I recall running into that, and finding some APIs that required > push/pop_cfun, so since I was implementing strub so that it could be > plugged into an existing compiler, I didn't give much thought to > introducing alternate APIs that could. IIRC I first hit something about > EH, and then I had to put in push/pop_cfun. That was very early on, so > after that I may have used implicit-cfun APIs without getting ICEs. I > suppose now that strub is in pursuing push/pop_cfun avoidance could be a > nice cleanup. Yeah, adding API variants with explicit struct function is considered OK when that allows to avoid push/pop_cfun. When playing with stmts the first thing you'll hit is update_stmt (though it's core worker, update_stmt_operands has the arg already). Sometimes the cfun dependence isn't really obvious ... > > I see you replace flag_exceptions with opt_for_fn (cfun->decl, > > flag_exceptions), given that's 'cfun' this replacement is a no-op > > given 'cfun' would be NULL in IPA context unless you pushed a function. > > > Looking at the 2nd hunk and the caller it seems the transform is > > a no-op for indrect_calls but not callees, thus that hunk is OK. > > Yeah, I figured that was the reason behind your recommendation, but I > guess adding explicit uses of cfun (rather than passing a function > around) doesn't really make things much better, except inasmuchas it > enables a future de-cfun-ification of strub passes to be a little more > mechanical. Yep, we've gone through some of GCCs APIs where there was two variants, one with and one without explicit struct function arg and eliminating the first in favor of explicit mentioning of 'cfun' to show where we depend on that. That was in the context of eventually threading parts of GCC which of course doesn't play well with this kind of global state. Richard.