From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 806 invoked by alias); 5 Dec 2013 23:34:49 -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 794 invoked by uid 89); 5 Dec 2013 23:34:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pb0-f49.google.com Received: from Unknown (HELO mail-pb0-f49.google.com) (209.85.160.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 05 Dec 2013 23:34:47 +0000 Received: by mail-pb0-f49.google.com with SMTP id jt11so26538537pbb.8 for ; Thu, 05 Dec 2013 15:34:40 -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=rB0VQYVnWW6zBJMft5+3QqMLxetZfjDHCt26T4MjC0c=; b=L0W/RJDmG8ZeBoXNnkje2wxNAxKafQe1eJi4nRkQHzsr8YlZWMX0ljdlb6Lkr1GVX3 Ovfy2+/oEysKB539aOD8khMy69oXy4aIuJIcfsLG3Q7h1YRMXHy1XEHHW3hctQLrAPaQ kQFNQ/kOGa1nFtG7VUjZyLBqlqRXG1k7kM6afI5CWe8M0olSNkvghcbz+mrJgEzombEB z3eqMBsZkdw6RqL5h72x8QFD9N9QpXrn9XqcpJ7L1LEdn0lCrrFKO8HMBHI7ulZGVrLi 8gha9U71gYlql1Gs8j5+1fcqUrljr0eFQPf3K/D20Kd2DxVRlZcpLigWX5wkj2H6EN8P 7p+Q== X-Gm-Message-State: ALoCoQkGGVMRX/sqCSCKmvLUD9rtRUNvSM1Od9pT/LaiHajg5MCa4oENwLgI3yk8V38Clh/UJSs/ X-Received: by 10.66.141.144 with SMTP id ro16mr314741pab.131.1386286479979; Thu, 05 Dec 2013 15:34:39 -0800 (PST) Received: from [192.168.1.142] (121-72-151-47.dsl.telstraclear.net. [121.72.151.47]) by mx.google.com with ESMTPSA id rx4sm170833093pab.13.2013.12.05.15.34.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 15:34:39 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: Dependency confusion in sched-deps From: Maxim Kuvyrkov In-Reply-To: <52A0D7AB.9050800@shmuelhome.mine.nu> Date: Thu, 05 Dec 2013 23:34:00 -0000 Cc: gcc Content-Transfer-Encoding: quoted-printable Message-Id: <456D5B9D-3994-49D0-822F-12A157B47281@kugelworks.com> References: <19EB96622A777C4AB91610E763265F463A3EB0@SJEXCHMB14.corp.ad.broadcom.com> <2ABA154D-7EAE-4422-AE0C-6E2E27F80235@kugelworks.com> <52A0D7AB.9050800@shmuelhome.mine.nu> To: shmeel gutl X-SW-Source: 2013-12/txt/msg00056.txt.bz2 On 6/12/2013, at 8:44 am, shmeel gutl wrote: > On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote: >> Dependency type plays a role for estimating costs and latencies between = instructions (which affects performance), but using wrong or imprecise depe= ndency type does not affect correctness. > On multi-issue architectures it does make a difference. Anti dependence p= ermits the two instructions to be issued during the same cycle whereas true= dependency and output dependency would forbid this. >=20 > Or am I misinterpreting your comment? On VLIW-flavoured machines without resource conflict checking -- "yes", it = is critical not to use anti dependency where an output or true dependency e= xist. This is the case though, only because these machines do not follow s= equential semantics for instruction execution (i.e., effects from previous = instructions are not necessarily observed by subsequent instructions on the= same/close cycles. On machines with internal resource conflict checking having a wrong type on= the dependency should not cause wrong behavior, but "only" suboptimal perf= ormance. Thank you, -- Maxim Kuvyrkov www.kugelworks.com