From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8728 invoked by alias); 10 Dec 2013 21:44:26 -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 8717 invoked by uid 89); 10 Dec 2013 21:44:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pb0-f41.google.com Received: from Unknown (HELO mail-pb0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Dec 2013 21:44:23 +0000 Received: by mail-pb0-f41.google.com with SMTP id jt11so8582255pbb.28 for ; Tue, 10 Dec 2013 13:44:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=04bAPOckLFFWBQYpdt4jzdcchNBbwogWxk49UkHMD24=; b=hTmBQ5y/9H4610Drl2+iRYwLxPq6g+Mt95uop9ISnOpeIGubSCQN35TZL0inlmUpBE IGvZg/QMtvoP+Bw31ukyvRTIxYsXog4I/insG22HGInSGlMf7dUbcsE/qjE1sGODH1Od xTKni8rZ5FnX+3AUV0gEJEfs1GpideaNQ3ZagqqIJxdKwGL99QR3CoL1lJr2AwB/va3V bl7k0423bLNuCb4uA4nbzGflwGG2vXzOng4iDRIvuUFOSjiRphMA2UkA1tyU9wG/51Zc sj4B5TU2zsfUFRlMrvpuRs4QIQvPnfVUEaCxXffrs0bNvjERgOPHQxqf2D0TLrlU2oPg cpBA== X-Gm-Message-State: ALoCoQkBanh7P9rikf0oSgIZwdxrzD7yRsC+0FNIlZ3UZs3hU7DWE1zWmNPvtCnR/FudruUJsX1u X-Received: by 10.66.170.138 with SMTP id am10mr30523408pac.51.1386711855374; Tue, 10 Dec 2013 13:44:15 -0800 (PST) Received: from [192.168.0.130] (121-98-52-31.bng1.nct.orcon.net.nz. [121.98.52.31]) by mx.google.com with ESMTPSA id ql10sm27854090pbc.44.2013.12.10.13.44.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:44:14 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: DONT_BREAK_DEPENDENCIES bitmask for scheduling From: Maxim Kuvyrkov In-Reply-To: Date: Tue, 10 Dec 2013 21:44:00 -0000 Cc: Paulo Matos , "gcc@gcc.gnu.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6F040EA5-5398-4FB8-9518-6C12EF22B5CD@kugelworks.com> References: <19EB96622A777C4AB91610E763265F46231E97@SJEXCHMB14.corp.ad.broadcom.com> To: ramrad01@arm.com X-SW-Source: 2013-12/txt/msg00135.txt.bz2 On 11/12/2013, at 5:17 am, Ramana Radhakrishnan = wrote: > On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote: >> Hi, >>=20 >> Near the start of schedule_block, find_modifiable_mems is called if DONT= _BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems on c6= x backend currently uses this. >> However, it's quite strange that this is not a requirement for all backe= nds since find_modifiable_mems, moves all my dependencies in SD_LIST_HARD_B= ACK to SD_LIST_SPEC_BACK even though I don't have DO_SPECULATION enabled. >>=20 >> 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_modifiabl= e_mems, given that it seems to 'literally' break dependencies. >>=20 >> Is the behaviour of find_modifiable_mems a bug or somehow expected? "Breaking" a dependency in scheduler involves modification of instructions = that would allow scheduler to move one instruction past the other. The mos= t common case of breaking a dependency is "r2 =3D r1 + 4; r3 =3D [r2];" whi= ch can be transformed into "r3 =3D [r1 + 4]; r2 =3D r1 + 4;". Breaking a d= ependency is not ignoring it, speculatively or otherwise; it is an equivale= nt code transformation to allow scheduler more freedom to fill up CPU cycle= s. >=20 >=20 > 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. O= n an architecture that supports speculative scheduling with recovery (IA64)= it can turn this feature on or off. The documentation for various feature= s of sched-rgn, sched-ebb and sel-sched is not the best and one will likely= get weird artefacts by trying out non-default settings. I believe that only IA64 backend supports selective scheduling reliably. I= 've other ports trying out selective scheduling, but I don't know whether t= hose efforts got positive results. -- Maxim Kuvyrkov www.kugelworks.com