From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id B62173858D35 for ; Thu, 16 Mar 2023 11:22:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B62173858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678965725; h=from:from:reply-to:reply-to:subject:subject: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=fJSijW6FRBuqHHzbCgFB4JgMuIXYtxeZQ81lUManL9U=; b=Jv5vpy9keR0L80ef5PSfMbF0s0N35FBPvtWnfnKmQtHIP4mIsZ0VuH2NwkUwmQPZc7cGbw 7iclYes3br78qqEHCRRH/RqARmYOnGLsFBrGf30Msd8JX9EICjWUje4HGUhVV8sBg4xQUS TdDGmjkuj/JdNc8xinfiSW/hjP/n6Ic= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-92-bDmp3Xo-PCGxrgFzjOW0Yg-1; Thu, 16 Mar 2023 07:22:02 -0400 X-MC-Unique: bDmp3Xo-PCGxrgFzjOW0Yg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id EB339811E7E; Thu, 16 Mar 2023 11:22:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 91D6F492B00; Thu, 16 Mar 2023 11:22:01 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 32GBLwQ42887350 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 16 Mar 2023 12:21:59 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 32GBLvd12887349; Thu, 16 Mar 2023 12:21:57 +0100 Date: Thu, 16 Mar 2023 12:21:57 +0100 From: Jakub Jelinek To: Richard Biener Cc: Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 Fri, Nov 25, 2022 at 09:26:34PM +0100, Richard Biener via Gcc-patches wrote: > > We could > > probably keep tract if any instrumented code was ever inlined into a > > given function and perhaps just start ignoring attributes set on types? > > But ignoring attributes on types makes all indirect calls not > const/pure annotatable (OK, they are not pure annotatable because of > the above bug). I really don't see how to conservatively solve this > issue? > Maybe we can ignore all pure/const when the cgraph state is > in profile-instrumented state? Of course we have multiple "APIs" > to query that. I think that's the way to go. But we'd need to arrange somewhere during IPA to add vops to all those pure/const calls if -fprofile-generate (direct or indirect; not sure what exact flags) and after that make sure all our APIs don't return ECF_CONST, ECF_PURE or ECF_LOOPING_CONST_OR_PURE. Could be e.g. if (whatever) flags &= ~(ECF_CONST | ECF_PURE | ECF_LOOPING_CONST_OR_PURE); at the end of flags_from_decl_or_type, internal_fn_flags, what else? Although, perhaps internal_fn_flags don't need to change, because internal calls don't really have callees. Or is just ECF_CONST enough given that ECF_PURE is on fndecls and not types? Or perhaps just start ignoring TYPE_READONLY -> ECF_CONST in flags_from_decl_or_type if that flag is on? Is that rewriting currently what tree_profiling does in the /* Update call statements and rebuild the cgraph. */ FOR_EACH_DEFINED_FUNCTION (node) spot where it calls update_stmt on all call statements? If so, could we just set that global? flag instead or in addition to doing those node->set_const_flag (false, false); calls and change flags_from_decl_or_type, plus I guess lto1 should set that flag if it is global on start as well if !flag_auto_profile && (flag_branch_probabilities || flag_test_coverage || profile_arc_flag) ? I think just ignoring ECF_CONST from TYPE_READONLY might be best, if we have external functions like builtins from libc/libm and don't have their bodies, we can still treat them as const, the only problem is with the indirect calls where we don't know if we do or don't have a body for the callees and whether we've instrumented those or not. Jakub