From patchwork Tue Aug 28 09:24:24 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Igor Zamyatin X-Patchwork-Id: 180386 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 925AC2C009D for ; Tue, 28 Aug 2012 19:24:52 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1346750692; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=lrncqcnxor4SjzQakCIZl5zT/9g=; b=np1Jm6+MEUNy+rOTWWyrtM+3YgJVXlcLSkuz4+chaNaoipMSPCzfzyZ++YniBD rnjGOLrSYWBnHW2RFH1h2Ps1oQcqAo+P6iDMwsz/7CUHujn6nseER/rX3vIlhMIr +F6m1LzbK4Sp7/8YrjSJR0STT4nbTgcx29nkad8jjBGDI= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=lwuvtQPJXp1JiGrvnbeuZiQGZM9h9SueQgzkPcH7pApPMIPmgg3BteTRt8DSWr QkhhLxsY7ZvvxfH5S0r7zgQtQ4H2hTyUD2/FZPbUu0qwZzx35QhajsBUpWA0B3mH PGHkFIK0nkiSiNDvsWFUCL/MFQUDmjZQVmTeUWJzc/g7Y=; Received: (qmail 3602 invoked by alias); 28 Aug 2012 09:24:46 -0000 Received: (qmail 3588 invoked by uid 22791); 28 Aug 2012 09:24:45 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE, TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Aug 2012 09:24:25 +0000 Received: by pbcwy7 with SMTP id wy7so8928871pbc.20 for ; Tue, 28 Aug 2012 02:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.195.230 with SMTP id ih6mr36612004pbc.100.1346145864915; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) Received: by 10.68.238.130 with HTTP; Tue, 28 Aug 2012 02:24:24 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Aug 2012 13:24:24 +0400 Message-ID: Subject: Re: [PATCH, x86-Atom] Enabling look-ahead scheduling feature for Atom processors From: Igor Zamyatin To: Uros Bizjak Cc: gcc-patches@gcc.gnu.org Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi! I'd like this patch (original version at the bottom) also to be backported into 4.7. Is it safe to backport? On Fri, Aug 24, 2012 at 11:35 AM, Uros Bizjak wrote: > On Fri, Aug 24, 2012 at 9:22 AM, Igor Zamyatin wrote: > >> Following change enables look ahead feature in the code scheduler for >> Atom processors. This gives quite reasonable gain for some benchmarks >> for mobile market. >> >> Overall compile time increase for SPEC2000 is about 1%. >> >> Regtested for x86_64 and also bootstrapped with "--with-arch=core2 >> --with-cpu=atom" >> >> 2012-08-23 Yuri Rumyantsev >> >> * config/i386/i386.c (ia32_multipass_dfa_lookahead) : Add >> case for Atom processor. > > OK. > > Thanks, > Uros. Original patch: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 976bbb4..331e29a 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -24103,6 +24103,7 @@ ia32_multipass_dfa_lookahead (void) case PROCESSOR_CORE2_64: case PROCESSOR_COREI7_32: case PROCESSOR_COREI7_64: + case PROCESSOR_ATOM: /* Generally, we want haifa-sched:max_issue() to look ahead as far as many instructions can be executed on a cycle, i.e., issue_rate. I wonder why tuning for many CPUs does not do this. */