From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45017 invoked by alias); 28 Jun 2018 08:57:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 45008 invoked by uid 89); 28 Jun 2018 08:57:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=possibilities X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 28 Jun 2018 08:57:54 +0000 Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Jun 2018 01:57:52 -0700 Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by fmsmga005.fm.intel.com with ESMTP; 28 Jun 2018 01:57:48 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.136]) by IRSMSX107.ger.corp.intel.com ([169.254.10.238]) with mapi id 14.03.0319.002; Thu, 28 Jun 2018 09:57:48 +0100 From: "Nesterovskiy, Alexander" To: Jeff Law , "gcc-patches@gcc.gnu.org" Subject: RE: [patch, i386] false dependencies fix Date: Thu, 28 Jun 2018 08:57:00 -0000 Message-ID: <8C9F785C3807D5499FF3CAD8623EEDCE21436F3D@IRSMSX103.ger.corp.intel.com> References: <8C9F785C3807D5499FF3CAD8623EEDCE21331D6F@IRSMSX103.ger.corp.intel.com> <4601ab4c-8df4-20f6-5c5d-735fd87bc605@redhat.com> In-Reply-To: <4601ab4c-8df4-20f6-5c5d-735fd87bc605@redhat.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg01777.txt.bz2 Hello! > So what I'm confused about is in the original output template operand=20 > 0 is duplicated. In the new template operand 1 is duplicated. > > Presumably what you're trying to accomplish is avoiding a false read=20 > on operand 0 (the destination)? Can you please confirm? > Knowing that should also help me evaluate the changes to recp and=20 > rsqrt since they're being changed to the same style encoding when=20 > operating strictly on registers. Yes, it's the same for all instructions in the patch - we're not just avoid= ing read but present more possibilities to execute speculatively for CPU here. The destination depends only on the source after the patch, and (thanks to CPU register renaming) CPU can successfully execute this instruction even if some previous instruction with write to the same destination is not finished currently. -- Alexander Nesterovskiy