From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28105 invoked by alias); 29 Aug 2008 16:33:24 -0000 Received: (qmail 28085 invoked by uid 22791); 29 Aug 2008 16:33:20 -0000 X-Spam-Check-By: sourceware.org Received: from fg-out-1718.google.com (HELO fg-out-1718.google.com) (72.14.220.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 29 Aug 2008 16:32:40 +0000 Received: by fg-out-1718.google.com with SMTP id e21so586238fga.28 for ; Fri, 29 Aug 2008 09:32:36 -0700 (PDT) Received: by 10.86.83.2 with SMTP id g2mr2223647fgb.54.1220027556723; Fri, 29 Aug 2008 09:32:36 -0700 (PDT) Received: from ?10.0.0.27? ( [91.78.54.213]) by mx.google.com with ESMTPS id 4sm2986170fge.8.2008.08.29.09.32.34 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Aug 2008 09:32:35 -0700 (PDT) Message-ID: <48B8249D.6000800@ispras.ru> Date: Sun, 31 Aug 2008 13:35:00 -0000 From: Andrey Belevantsev User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: David Edelsohn CC: GCC Patches , Jim Wilson , Vladimir Makarov , Ayal Zaks , Mark Mitchell Subject: Re: Selective scheduling pass - target changes (ia64 & rs6000) [3/3] References: <303e1d290808280820p6497e7bdy614393a4c0bd5377@mail.gmail.com> In-Reply-To: <303e1d290808280820p6497e7bdy614393a4c0bd5377@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; 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: 2008-08/txt/msg02407.txt.bz2 Hello, David Edelsohn wrote: > * config/rs6000/rs6000.c (rs6000_init_sched_context, > rs6000_alloc_sched_context, rs6000_set_sched_context, > rs6000_free_sched_context): New functions. > (struct _rs6000_sched_context): New. > (rs6000_sched_reorder2): Do not modify INSN_PRIORITY for selective > scheduling. > (rs6000_sched_finish): Do not run for selective scheduling. > > The rs6000 part of the patch is okay with a modification to the following chunk: Thanks for the review, I'll fix that up. > Also, target maintainers have flexibility during stage 3 with respect > to changes local to a port, > so the Itanium changes can be approved and committed during stage 3, > although earlier would > be better. I didn't know that. But, what would be the preferred policy for checking in the scheduler in this case? Should I wait for the Itanium changes to be reviewed and then commit the whole patch, which means that target-independent changes would be committed during stage3? Or, should I check in the scheduler without ia64 changes now, which means it will be non-functional on Itanium, and commit to reverting it in case the ia64 changes will not be reviewed even during stage 3? I'll appreciate the advice on how to proceed. Thanks, Andrey