From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5894 invoked by alias); 10 Dec 2013 22:14:30 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5837 invoked by uid 89); 10 Dec 2013 22:14:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qe0-f54.google.com Received: from Unknown (HELO mail-qe0-f54.google.com) (209.85.128.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Dec 2013 22:14:27 +0000 Received: by mail-qe0-f54.google.com with SMTP id cy11so4621586qeb.13 for ; Tue, 10 Dec 2013 14:14:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.49.116.78 with SMTP id ju14mr154513137qeb.57.1386713659045; Tue, 10 Dec 2013 14:14:19 -0800 (PST) Received: by 10.224.194.193 with HTTP; Tue, 10 Dec 2013 14:14:18 -0800 (PST) Reply-To: ramrad01@arm.com In-Reply-To: <6F040EA5-5398-4FB8-9518-6C12EF22B5CD@kugelworks.com> References: <19EB96622A777C4AB91610E763265F46231E97@SJEXCHMB14.corp.ad.broadcom.com> <6F040EA5-5398-4FB8-9518-6C12EF22B5CD@kugelworks.com> Date: Tue, 10 Dec 2013 22:14:00 -0000 Message-ID: Subject: Re: DONT_BREAK_DEPENDENCIES bitmask for scheduling From: Ramana Radhakrishnan To: Maxim Kuvyrkov Cc: Paulo Matos , "gcc@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00137.txt.bz2 On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrot= e: > On 11/12/2013, at 5:17 am, Ramana Radhakrishnan wrote: > >> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote: >>> Hi, >>> >>> Near the start of schedule_block, find_modifiable_mems is called if DON= T_BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems on c= 6x backend currently uses this. >>> However, it's quite strange that this is not a requirement for all back= ends since find_modifiable_mems, moves all my dependencies in SD_LIST_HARD_= BACK to SD_LIST_SPEC_BACK even though I don't have DO_SPECULATION enabled. >>> >>> Since dependencies are accessed later on from try_ready (for example), = I would have thought that it would be always good not to call find_modifiab= le_mems, given that it seems to 'literally' break dependencies. >>> >>> Is the behaviour of find_modifiable_mems a bug or somehow expected? > > "Breaking" a dependency in scheduler involves modification of instruction= s that would allow scheduler to move one instruction past the other. The m= ost common case of breaking a dependency is "r2 =3D r1 + 4; r3 =3D [r2];" w= hich can be transformed into "r3 =3D [r1 + 4]; r2 =3D r1 + 4;". Breaking a= dependency is not ignoring it, speculatively or otherwise; it is an equiva= lent code transformation to allow scheduler more freedom to fill up CPU cyc= les. Yes, but there are times when it does this a bit too aggressively and this looks like the cause for a performance regression that I'm investigating on ARM. I was looking for a way of preventing this transformation and there doesn't seem to be an easy one other than the obvious hack. Additionally there appears to be no way to control "flags" in a backend hook for sched-rgn for DONT_BREAK_DEPENDENCIES . Again if the DONT_BREAK_DEPENDENCIES is meant to be disabled with these flags, then it looks like we should allow for these to also be handled or describe TARGET_SCHED_SET_SCHED_FLAGS as only a hook valid with the selective scheduler. > >> >> >> It's funny how I've been trying to track down a glitch and ended up >> asking the same question today. Additionally if I use >> TARGET_SCHED_SET_SCHED_FLAGS on a port that doesn't use the selective >> scheduler, this does nothing. Does anyone know why is this the default >> for ports where we don't turn on selective scheduling and might need a >> hook to turn this off ? > > SCHED_FLAGS is used to enable or disable various parts of GCC scheduler. = On an architecture that supports speculative >scheduling with recovery (IA= 64) it can turn this feature on or off. The documentation for various feat= ures of sched-rgn, sched-ebb and sel-sched is not the best and one will lik= ely get weird artefacts by trying out non-default settings. Well, it appears as though TARGET_SCHED_SET_SCHED_FLAGS is only valid with the selective scheduler on as above and is a no-op as far as sched-rgn goes. This whole area could do with some improved documentation - I'll follow up with some patches to see if I can improve the situation. Thanks for your reply though. regards Ramana > > -- > Maxim Kuvyrkov > www.kugelworks.com > >