From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F2E873858C54; Wed, 29 Mar 2023 15:04:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F2E873858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1680102243; bh=7SdNZIMyR2kdN9XSxz2xtTLARvf22X09Xt4qf8B5BWE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=alD0mx2KK+10JfvxWP1zjIeHXs8mKdsU7H7wvnTW4L2yMCXbi3/35wUlMpQ3W3/l6 noC9A5x9jtGtCRVK4uj5mNC3Dl1C8l8YBe/3Tz0Diqfx2LdITUqR4zfz+urJUmGHNl /ZogBK2hw2e288wR0x5me1/pnDJZy/fvPPDX6ojE= From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723 Date: Wed, 29 Mar 2023 15:04:03 +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: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 13.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D109213 --- Comment #8 from Jan Hubicka --- We have large-stack-frame-growth that is relative, so yes, increasing stack size of caller makes gcc to think that it is heavy and making it event heav= ier will not hurt that much. We originally ran into stack size growth issues after implementing logic to inline functions called once. In things like glibc printf where we ended up inlining some exotic formater (as called once) that made the stack too large for multithreaded apps. Also sometimes we inlined some heavy function that= is off the hot path. While relative growth cap may not be best possible for all cases, I can't think of reasonable way doing this better. With the new code to determine basic blocks that are executed at every execution of the function I plan to relax stack size limits a bit by bypass= ing them when the call is known to be always allocated (and thus the stack will= be always taken) This is also relatively common problem in Fortran where fortran IO (typical= ly done somewhere in debug code) tends to crate large on-stack structures preventing inlining.=