From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12333 invoked by alias); 8 Jul 2011 07:26:32 -0000 Received: (qmail 12310 invoked by uid 22791); 8 Jul 2011 07:26:31 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.198.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 08 Jul 2011 07:26:05 +0000 Received: from [10.10.3.52] (winnie.ispras.ru [83.149.198.236]) by smtp.ispras.ru (Postfix) with ESMTP id C9BC15D406A; Fri, 8 Jul 2011 11:19:05 +0400 (MSD) Message-ID: <4E16B106.2090509@ispras.ru> Date: Fri, 08 Jul 2011 08:27:00 -0000 From: Andrey Belevantsev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vladimir Makarov CC: Bernd Schmidt , GCC Patches Subject: Re: Fix PR 49014 References: <4DDCBC02.7020002@ispras.ru> <4DDD1528.8060200@codesourcery.com> <4DDD2043.1080703@ispras.ru> <4DDD20CE.4000707@codesourcery.com> <4DDE5657.4000601@ispras.ru> <4E0DDEBA.5000804@ispras.ru> <4E15DC5B.6010900@redhat.com> In-Reply-To: <4E15DC5B.6010900@redhat.com> 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: 2011-07/txt/msg00588.txt.bz2 On 07.07.2011 20:18, Vladimir Makarov wrote: > On 07/01/2011 10:50 AM, Andrey Belevantsev wrote: >> On 26.05.2011 17:32, Andrey Belevantsev wrote: >>> On 25.05.2011 19:31, Bernd Schmidt wrote: >>>> On 05/25/2011 03:29 PM, Andrey Belevantsev wrote: >>>>> I think the hook is a better idea than the attribute because nobody will >>>>> care to mark all offending insns with an attribute. >>>> >>>> I don't know. IIRC when I looked at sh or whatever the broken port was, >>>> it was only two insns - there would still be some value in being able to >>>> assert that all other insns have a reservation. >>> OK, I will take a look on x86-64 and will get back with more information. >>> >>> Andrey >> So, I have made an attempt to bootstrap on x86-64 with the extra assert >> in selective scheduling that assumes the DFA state always changes when >> issuing a recog_memoized >=0 insn (patch attached). Indeed, there are >> just a few general insns that don't have proper reservations. However, it >> was a surprise to me to see that almost any insn with SSE registers fails >> this assert and thus does not get properly scheduled. >> >> Overall, the work on fixing those seems doable, it took just a day to get >> the compiler bootstrapped (of course, the testsuite may bring much more >> issues). So, if there is an agreement on marking a few offending insns >> with the new attribute, we can proceed with the help of somebody from the >> x86 land on fixing those and researching for other targets. >> > The changes in sel-sched.c is ok for me. i386.md changes look ok for me too > but you should ask a x86 maintainer to get an approval for the change. > > I think you should describe the attribute in the documentation because it > is common for all targets. > > I can not approve common.opt changes because it makes selective scheduler > is default for the 2nd insn scheduling for all targets. Such change should > be justified by thorough testing and benchmarking (compilation speed, code > size, performance improvements) on several platforms (at least on major ones). I didn't intend to enable sel-sched for all targets, the patch was just an RFC to see whether there is an agreement about usefulness of such attribute, and the common.opt change was to show how I tested the patch. I am sorry for not making it clear in the mail. I am planning to check Bernd's thought about whether I selected the right -mcpu switch for testing, as I was under impression that nowadays this should be autodetected by configure. I will also modify the attribute as suggested. Then we can discuss further. I am going to leave on vacation soon though so I don't know when exactly I can proceed with this. Thanks! Andrey