From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 02F763858005; Sun, 28 Nov 2021 19:07:38 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 02F763858005 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies Date: Sun, 28 Nov 2021 19:07:38 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: missed-optimization, ra 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: 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: Sun, 28 Nov 2021 19:07:39 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98782 --- Comment #6 from Jan Hubicka --- I am sorry for getting back to this again late. This stage1 we spent some = time with Martin improving the ipa-cp profile updating and looked again into the realism of the profile. Also recently the codegen has improved somewhat due= to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103227 and due to modref propagation. I still believe for trunk GCC we should not have patch that intentionally m= akes profile unrealistic just to make IRA work better by accident since it does = not seem to help anything real world except this somewhat odd benchmark. So I wonder if we can make profile to work better for IRA without actually makin= g it unrealistic and tampering with ipa-cp cloning heuristics I added code that compares guessed profile with feedback https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585599.html and also fixed/improved code to dump stats about profile updates https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585578.html This gives bit more handle on how realistic the profile is. Answer is that= not very in general, but at least for basic blocks containing calls it is not b= ad (we guess 0.9 while relity is 0.999). I am not sure how much better we can do statically since this is such a spe= cial case of backtracking. Last week we also noticed that with -Ofast we inline the newly produced clo= nes together which makes IRA job a lot harder. This is done by -finline-functions-called-once and we tend to inline blocks of 2 or 3 clones leading to 18 or 27 nested loops in each. Simply disabling this optimizati= on gets another performance hit. I filled in PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103454 and I = think we could teach the inliner to not inline functions called once in large loop depths and restrict the large functions growths here since there are multip= le benchmarks that now degrade on this. Worse yet, the heuristics for inlininig functions called once is not very s= mart and it depends on the order of cgrpah_nodes in the linked list which is bit random. I wonder how the situation looks on AArch64?=