From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Envelope-to: publicinbox@libre-riscv.org Delivery-date: Sat, 16 May 2020 10:47:30 +0100 Received: from localhost ([::1] helo=libre-riscv.org) by libre-soc.org with esmtp (Exim 4.89) (envelope-from ) id 1jZtPl-0005pq-Qi; Sat, 16 May 2020 10:47:29 +0100 Received: from vps2.stafverhaegen.be ([85.10.201.15]) by libre-soc.org with esmtp (Exim 4.89) (envelope-from ) id 1jZtPk-0005pk-Bd for libre-riscv-dev@lists.libre-riscv.org; Sat, 16 May 2020 10:47:28 +0100 Received: from hpdc7800 (hpdc7800 [10.0.0.1]) by vps2.stafverhaegen.be (Postfix) with ESMTP id 063D111C04FF for ; Sat, 16 May 2020 11:47:27 +0200 (CEST) Message-ID: From: Staf Verhaegen To: libre-riscv-dev@lists.libre-riscv.org Date: Sat, 16 May 2020 11:47:27 +0200 In-Reply-To: References: <747F8870-06C6-46A0-AFD9-D55289D4C41A@gatech.edu> <4BDA96A5-9063-42A6-9548-CAE3CBEBEBAC@gatech.edu> Organization: FibraServi bvba X-Mailer: Evolution 3.28.5 (3.28.5-8.el7) Mime-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 Subject: Re: [libre-riscv-dev] Introduction and Questions X-BeenThere: libre-riscv-dev@lists.libre-riscv.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Libre-RISCV General Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Libre-RISCV General Development Content-Type: multipart/mixed; boundary="===============6853962972487324962==" Errors-To: libre-riscv-dev-bounces@lists.libre-riscv.org Sender: "libre-riscv-dev" Archived-At: List-Archive: --===============6853962972487324962== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-aNfOkJazDJL9i8Rts+Jp" --=-aNfOkJazDJL9i8Rts+Jp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeremy Singher schreef op vr 15-05-2020 om 16:49 [-0700]: >=20 > >=20 > > sigh over a year ago i understood this enough to be able to answer. > > what we will have to do is simply ignore the optimisation opportunity. >=20 >=20 > Hmmm, ignoring WAW will significantly limit the ability of the core to > exploit ILP, which is one of the fundamental reasons for going OOO. I've wondered about this myself. Can you give concrete example of where not supporting a WAW hazard blocks ILP ? I am asking because just a WAW hazard could be easily avoided by a good peep hole optimizer in software because it would see that the output of the first write is never used. greets, Staf. --=-aNfOkJazDJL9i8Rts+Jp-- --===============6853962972487324962== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlicmUtcmlz Y3YtZGV2IG1haWxpbmcgbGlzdApsaWJyZS1yaXNjdi1kZXZAbGlzdHMubGlicmUtcmlzY3Yub3Jn Cmh0dHA6Ly9saXN0cy5saWJyZS1yaXNjdi5vcmcvbWFpbG1hbi9saXN0aW5mby9saWJyZS1yaXNj di1kZXYK --===============6853962972487324962==--