From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 9BD7B384781A; Wed, 23 Mar 2022 17:23:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9BD7B384781A From: "aldyh at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object Date: Wed, 23 Mar 2022 17:23:12 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic, missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: aldyh at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 12.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 17:23:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104475 --- Comment #10 from Aldy Hernandez --- (In reply to Richard Biener from comment #9) > I think threading unlikely paths is never worth it and usually NULL point= er > checks are statically predicted. >=20 > I guess one idea would be to scale BB cost based on entry_BB->count vs. > BB->count so we more quickly run into the threading size limit for unlike= ly > executed blocks? Likewise since we first evaluate all threading > opportunities in a function (do we?) we should sort them so we first thre= ad > the "best" one and use a global threading limit instead one applied to ea= ch > individual path (so we'd just stop threading once we hit the limit). Yes, we first queue all threading opportunities and then reorganize the blo= cks at the end. >=20 > Can we, for GCC 12, at least stop threading !maybe_hot_edge_p()? Eventua= lly > we can produce sth like a maybe_hot_threading_path_p () taking into accou= nt > the whole path. Sure, sounds reasonable, especially since as we get the last holdout conver= ted to the new model (DOM threading), we'll have even more threading opportunit= ies which could use some pruning. The whole cost model, as well as profiling, etc, was beyond the scope of my work this year. I'm curious if Jeff had any long term plans for this?=