From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1094 invoked by alias); 22 Dec 2010 21:02:53 -0000 Received: (qmail 1085 invoked by uid 22791); 22 Dec 2010 21:02:52 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_CF X-Spam-Check-By: sourceware.org Received: from mail-ey0-f179.google.com (HELO mail-ey0-f179.google.com) (209.85.215.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Dec 2010 21:02:47 +0000 Received: by eyg24 with SMTP id 24so2635545eyg.10 for ; Wed, 22 Dec 2010 13:02:44 -0800 (PST) Received: by 10.213.3.11 with SMTP id 11mr4218964ebl.67.1293051764779; Wed, 22 Dec 2010 13:02:44 -0800 (PST) Received: from [192.168.1.100] (broadband-95-84-183-240.nationalcablenetworks.ru [95.84.183.240]) by mx.google.com with ESMTPS id b52sm5011644eei.13.2010.12.22.13.02.42 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Dec 2010 13:02:43 -0800 (PST) Message-ID: <4D12676E.5030003@ispras.ru> Date: Wed, 22 Dec 2010 22:44:00 -0000 From: Andrey Belevantsev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Alexander Monakov CC: gcc-patches@gcc.gnu.org, "Vladimir N. Makarov" Subject: Re: [PR47036] sel-sched: don't attempt to move up unconditional jumps References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg01733.txt.bz2 On 22.12.2010 20:57, Alexander Monakov wrote: > Hi, > > This patch drops bits of support for moving up unconditional jumps. The rest > of the scheduler does not handle it anyway, and most of the time dependencies > would prohibit such motion (in the testcase it's possible because other insns > are nops). While I'm happy with this patch, I would like to note that I'm rather tired of fixing various corner cases that are only seen in the scheduler when running it with -O0. I do believe that we need to force cleanup_cfg and DCE when not optimizing and stop caring. > > I've verified that the patch does not affect code generation on several cc1 .i > files at -O3 (targeting ia64). Bootstrapped on x86-64-linux, ia64-linux > (testsuite running). OK for trunk? I would also suggest to go further and check codegen differences on SPEC2k. Andrey