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 C6396385840E for ; Thu, 19 Jan 2023 07:00:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C6396385840E 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 21FA25C9C8; Thu, 19 Jan 2023 07:00:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1674111641; 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=WGVBMD3vhAtvmQmC9bomsdbk9XFoCTcKuXo5tMr89ug=; b=iA8PlOhjZYCfvi629ijgWOQ4vZiRHnKMROT+A+fSmIDm4ppC1ARJ95iYZInBCGlRHosOMS Bv+r/vKyJZFeEEY7eE0Qk+z/+yudAP/nTcoPufsy62Po8EtGQsickVGCxD4zx0Dt5eAq5a 7/EGTPLnykUP7epcgWmyk7+nwGgV+10= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1674111641; 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=WGVBMD3vhAtvmQmC9bomsdbk9XFoCTcKuXo5tMr89ug=; b=BekX8ASlyXhfeRyPLylNf3eUz8ZRWebpwPDPTISil6E2ir9eQzKuahgQP4IHXHRI/9VYVV /z12OIjsKf0eQiBA== 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 002E22C141; Thu, 19 Jan 2023 07:00:40 +0000 (UTC) Date: Thu, 19 Jan 2023 07:00:40 +0000 (UTC) From: Richard Biener To: Jan Hubicka cc: gcc-patches@gcc.gnu.org, ebotcazou@adacore.com Subject: Re: [PATCH] middle-end/106075 - non-call EH and DSE In-Reply-To: Message-ID: References: <20230117101319.BD5DD139C6@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=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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 Wed, 18 Jan 2023, Jan Hubicka wrote: > > On Tue, 17 Jan 2023, Jan Hubicka wrote: > > > > > > > We don't use same argumentation about other control flow statements. > > > > > The following: > > > > > > > > > > fn() > > > > > { > > > > > try { > > > > > i_read_no_global_memory (); > > > > > } catch (...) > > > > > { > > > > > reutrn 1; > > > > > } > > > > > return 0; > > > > > } > > > > > > > > > > should be detected as const. Marking throw pure would make fn pure too. > > > > > > > > I suppose i_read_no_global_memory is const here. Not sure why that > > > Suppose we have: > > > > > > void > > > i_read_no_global_memory () > > > { > > > throw(0); > > > } > > > > > > If cxa_throw itself was annotated as 'p' rahter than 'c' ipa-modref will > > > believe that cxa_throw will read any global memory and will propagate it > > > to all callers. So fn() will be also marked as reading all global > > > memory. > > > > Sure - but for the purpose of local optimizations in > > i_read_no_global_memory cxa_throw has to appear to read memory. > > Yes, I think every stmt that can throw externally need VUSE (just like > return_stmt needs it). Even if throw(0) was replaced by a=b/c with > -fnon-call-exceptions. It is still not clear to me why this should > imply that we need 'p' instead of 'c' in fnspecs. > > So I think we should try to make the following to work: > > diff --git a/gcc/tree-ssa-operands.cc b/gcc/tree-ssa-operands.cc > index 57e393ae164..d24f1721eb2 100644 > --- a/gcc/tree-ssa-operands.cc > +++ b/gcc/tree-ssa-operands.cc > @@ -951,6 +951,9 @@ operands_scanner::parse_ssa_operands () > enum gimple_code code = gimple_code (stmt); > size_t i, n, start = 0; > > + if (stmt_can_throw_external (fn, stmt)) > + append_vuse (gimple_vop (fn)); > + > switch (code) > { > case GIMPLE_ASM: It's going to be a bit tricky since in many places we use gimple_vuse () != NULL to check whether an assignment is a load/store. But yes, the above is sort-of what we'd need to do. > > Having a VUSE there dependent on whether the function performs any > > load or store would be quite ugly. Instead modref could special-case > > cxa_throw and not treat it as reading memory (like it already does > > for the return stmt I suppose - that also has a VUSE). > > modref looks into statements with VUSEs on them and checks what > reads/stores are done. So return statement with VUSE is walked and no > load is recorded because no actual load is found. > Similarly that would happen with __cxa_throw if it was 'c'. > With 'p' it has nothing to analyze so it would trust the fact that > cxa_throw itself reads some global state. I see. But does __cxa_throw stmt_can_throw_external ()? Otherwise the operand scanner elides VUSE on const function calls. > > > > The problem is IIRC GIMPLE_RESX which doesn't derive from > > gimple_statement_with_memory_ops_base. There's a bugzilla I can't find > > right now refering to this issue. > > I never tried to play with gimple hiearchy. It is hard to fix resx? I > wonder if we have other cases. I guess for a=b/c we are luck just > because gimple_assign can also be load or store so it has memory_ops... Fixing resx would come at the cost of deriving from _with_ops, but not sure if that waste of space is too important. Richard. > Thanks, > Honza > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)