From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54336 invoked by alias); 17 Mar 2015 22:15:39 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 54284 invoked by uid 48); 17 Mar 2015 22:15:35 -0000 From: "aoliva at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level Date: Tue, 17 Mar 2015 22:15:00 -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: 5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: aoliva at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-03/txt/msg01733.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #9 from Alexandre Oliva --- (In reply to Jeffrey A. Law from comment #7) > OK, but why does this make such a difference in the final result. Ie, what happens as we get into RTL. Err, I covered that bit in my description: we emit a number of copies, each with a new BB of its own. The additional pseudo survives all the way to the end, and so do the copies, which is enough to explain the additional stack slot. Further rearrangement of code also follows from the additional blocks. (In reply to Andrew Macleod from comment #8) > most of these kinds of restrictions were rooted in some kind of rationale... usually from examining an issue of some sort and introducing the restriction to avoid it. This one was added by https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00517.html The description mentions out-of-SSA coalescing, but not copyrename coalescing, which is what this is about. Since there were not anonymous SSA names before, the introduced condition would necessarily not be met, so it effectively reduced the amount of copyrename coalescing without any rationale AFAICT. Richi, do you happen to have any insight as to why you changed copyrename to avoid coalescing rootless ssa names? Reverting it doesn't seem to have any ill effects on code correctness (unlike allowing coalescing between rooted and rootless vars during out-of-ssa, in gimple_can_coalesce_p, which breaks codegen badly, though I haven't dug into why). I'll attach a patch I'm testing to that effect momentarily.