From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14865 invoked by alias); 11 Mar 2011 01:31:37 -0000 Received: (qmail 14856 invoked by uid 22791); 11 Mar 2011 01:31:37 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Mar 2011 01:31:33 +0000 From: "hp at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/37916] [4.3/4.4/4.5/4.6 Regression] SSA names causing register pressure; unnecessarily many simultaneously "live" names. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hp at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: hp at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.3.6 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 11 Mar 2011 01:31:00 -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 X-SW-Source: 2011-03/txt/msg01080.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37916 --- Comment #20 from Hans-Peter Nilsson 2011-03-11 01:31:14 UTC --- (In reply to comment #19) > Random thought on this PR: With a scheduler description, -fschedule-insns > -fsched-pressure may help. That theory should be testable by compiling for e.g. a x86_64 target; see comment #12, but to answer your question... > Is there a reason why there is no scheduler description? Yes. For a while, there was nothing to schedule. ...except for CPUs in systems a cache, where it helps to schedule to avoid RaW hazards. ...and then pipelined variants came, with other hazards to schedule (to avoid bubbles, no mips1-type madness). ...but then, I noticed that scheduling with the "new" scheduler wasn't supported for CC0 targets. ...which later was either fixed, or just a plain misunderstanding (cf. m68k/cf.md). ...and when checking the cycle-correct simulator, I found that there weren't many cycles to schedule away, hence a fair amount of work for no apparent gain, at least for the intended purpose of insn scheduling. There you go, the reasons in a nutshell. And while there's still a possibility that it's a pragmatic solution (modulo #c12), it doesn't strike me as requiring a scheduler to be the Right Thing to do for a fix to this problem. (Though from a general GCC maintenance perspective, automatically defaulting to a trivial scheduler might be a good idea.)