From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 2964938493CA for ; Mon, 13 Feb 2023 12:41:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2964938493CA 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 0445A1F37C; Mon, 13 Feb 2023 12:41:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1676292109; 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=QYwnC64hxxuNY7sUAYqSLzZ/wpfrXpuJ6+67KkxXQOM=; b=VVzQP6PId7rKf6jJ2bYWFFLIH61sV+sVRZefuUyH1IIfy0Ka6ziAuc1hafa7PbxyXLarea JDtadbaIofMNhbwaxCpmZ4/+58G2eGvXADCE0dE1GHLweVyCj8ueFVBJwQpFVl430IZWpH dn7w7/rzyx8+vu3gGUn+B1RNpFa0dgI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1676292109; 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=QYwnC64hxxuNY7sUAYqSLzZ/wpfrXpuJ6+67KkxXQOM=; b=QAyVWPDN64LmNQUhqKeDQChXf55I/tdQ+5AzK+b3dGA5gHLjFHU6Z1LcJMOwQusx/U9Q3L RYhWPo/idHUbSECQ== 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 1033E2C141; Mon, 13 Feb 2023 12:41:48 +0000 (UTC) Date: Mon, 13 Feb 2023 12:41:48 +0000 (UTC) From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/108691 - indirect calls to setjmp In-Reply-To: Message-ID: References: <20230213110058.0C9B61391B@imap2.suse-dmz.suse.de> 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP 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, 13 Feb 2023, Jakub Jelinek wrote: > On Mon, Feb 13, 2023 at 12:00:56PM +0100, Richard Biener wrote: > > DCE now chokes on indirect setjmp calls becoming direct because > > that exposes them too late to be subject to abnormal edge creation. > > The following patch honors gimple_call_ctrl_altering for those and > > _not_ treat formerly indirect calls to setjmp as calls to setjmp. > > > > Unfortunately there's no way to have an indirect call to setjmp > > properly annotated (the returns_twice attribute is ignored on types). > > > > RTL expansion late discovers returns-twice for the purpose of > > adding REG_SETJMP notes and also sets ->calls_setjmp > > (instead of asserting it is set). There's no good way to > > transfer proper knowledge around here so I'm using ->calls_setjmp > > as a flag to indicate whether gimple_call_ctrl_altering was set. > > > > Comments on what's the most sensible thing to do here? Supporting > > returns_twice on indirect calls wouldn't be difficult, so we're > > talking about how to handle this kind of "legacy" situation? > > One thing is supporting returns_twice on function types, but another one > is that initially none of the calls will be marked that way and even later, > it is up to the user if they mark it or not. Yep. > Could we e.g. prevent turning such indirect calls into direct calls? We do exactly have gimple_call_fntype and gimple_call_ctrl_altering_p to not require special-casing indirect to direct call promotion here. > Anyway, notice_special_calls is called in various spots, not just DCE, > wouldn't it be better to simply not set calls_setjmp flag in there if > the current function already has cfg and the call isn't ctrl altering? I thought about changing gimple_call_flags instead, filtering out ECF_RETURNS_TWICE. I just didn't make up my mind on what property to key at (and to require 'cfun' to be set to query it). But sure, changing notice_special_calls also works - the only other relevant caller is the inliner I think, and that could be replaced by caller |= callee of the two flags tracked instead of re-scanning each inlined stmt. Would you be happy with changing notice_special_calls, dropping the DCE hunk but keeping the cfgexpand/calls.cc hunks? Thanks, Richard.