From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20753 invoked by alias); 10 Dec 2013 21:55:39 -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 20722 invoked by uid 89); 10 Dec 2013 21:55:38 -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-f52.google.com Received: from Unknown (HELO mail-pb0-f52.google.com) (209.85.160.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 10 Dec 2013 21:55:37 +0000 Received: by mail-pb0-f52.google.com with SMTP id uo5so8618308pbc.11 for ; Tue, 10 Dec 2013 13:55:30 -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=T3yNjts0Un8L4Hnqlm+M0sULhtc0p8cOe0OoTHPCkXk=; b=hAVwK7j36H1EiNeEbTvnXdXRzvvi5aXxsyXBuHu+ihXtGbLHxQjU1hE9LmGF6pucW8 CzxHaxFDKrgGg3svxyXdFllRMJgqcq8/FrFvcXcRN/v8JLTzvkO2PrJwCHWO8fAbt0uz ClmtvaH3VUI8zQ1PV5FJi3LT9bgbLWaMOqydM95vhDzdlWafZbTuqRFMiF8bHa4/fkEa /jOjRiuMOGCcsA/If2km2ntIgpZyK5uIv268+0mcjV/r/YYRfvP7Sg/9O9muShkYex8V JPi7/vSKHV7efHo/08qOgdSRp1/O2CEsD+/aB6mtEpWIN58bhkCg55HjfVPkeIoli3oz hA6g== X-Gm-Message-State: ALoCoQkwEb9xsu15i8WjQvgyLE9MTOZr0IvVqZD92sMzrzQDcWOtzoDt7gYa3+nG7UGUnYLuaYoz X-Received: by 10.68.66.33 with SMTP id c1mr30179099pbt.73.1386712530130; Tue, 10 Dec 2013 13:55:30 -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 hu10sm27920962pbc.11.2013.12.10.13.55.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 13:55:29 -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: <52A18E5E.1030104@shmuelhome.mine.nu> Date: Tue, 10 Dec 2013 21:55:00 -0000 Cc: gcc Content-Transfer-Encoding: quoted-printable Message-Id: References: <19EB96622A777C4AB91610E763265F463A3EB0@SJEXCHMB14.corp.ad.broadcom.com> <2ABA154D-7EAE-4422-AE0C-6E2E27F80235@kugelworks.com> <52A0D7AB.9050800@shmuelhome.mine.nu> <456D5B9D-3994-49D0-822F-12A157B47281@kugelworks.com> <52A18E5E.1030104@shmuelhome.mine.nu> To: shmeel gutl X-SW-Source: 2013-12/txt/msg00136.txt.bz2 On 6/12/2013, at 9:44 pm, shmeel gutl wrote: > On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote: >> On 6/12/2013, at 8:44 am, shmeel gutl wr= ote: >>=20 >>> On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote: >>>> Dependency type plays a role for estimating costs and latencies betwee= n instructions (which affects performance), but using wrong or imprecise de= pendency type does not affect correctness. >>> On multi-issue architectures it does make a difference. Anti dependence= permits the two instructions to be issued during the same cycle whereas tr= ue 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 dependenc= y exist. This is the case though, only because these machines do not follo= w sequential semantics for instruction execution (i.e., effects from previo= us instructions are not necessarily observed by subsequent instructions on = the same/close cycles. >>=20 >> On machines with internal resource conflict checking having a wrong type= on the dependency should not cause wrong behavior, but "only" suboptimal p= erformance. >>=20 >>=20 ... > Earlier in the thread you wrote >> Output dependency is the right type (write after write). Anti dependenc= y is write after read, and true dependency is read after write. > Should the code be changed to accommodate vliw machines.. It has been the= re since the module was originally checked into trunk. The usual solution for VLIW machines is to have assembler split VLIW bundle= s that have internal dependencies and execute them on different cycles. Th= e idea is for compiler to strive to do its best to produce code without any= internal dependencies, but it is up to assembler to do the final check and= fix any occasional problems. [A good assembler has to do this work anyway= to accommodate for mistakes in hand-written assembly.] The scheduler is expected to produces code with no internal dependencies fo= r VLIW machines 99% of the time. This 99% effectiveness is good enough sin= ce scheduler is often not the last pass that touches code, and subsequent t= ransformations can screw up VLIW bundles anyway. -- Maxim Kuvyrkov www.kugelworks.com