Message ID | 20231205022948.504790-3-hongyu.wang@intel.com |
---|---|
State | Unresolved |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3175890vqy; Mon, 4 Dec 2023 18:39:07 -0800 (PST) X-Google-Smtp-Source: AGHT+IEAn017QElvyLd7lfTlOrDKhAOYnBlQMBGT0XSr2dY5zsl4Qxb+s23aBEV4Px9kC0fhNte6 X-Received: by 2002:ac8:580e:0:b0:425:4043:18d0 with SMTP id g14-20020ac8580e000000b00425404318d0mr746628qtg.131.1701743947240; Mon, 04 Dec 2023 18:39:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1701743947; cv=pass; d=google.com; s=arc-20160816; b=ujnVVGYNR93Het7Ot81L/M//DZscecAs1zAYGaAf3+qcVZKq+IrLjYj146UHzi8yLc h6JHIs1HQkvCOFa6i6cslcGMC3nzRobKe3IYTKuqXvJ1VpKevZqYzim3KRnQ60LijuPw fjnx+kzCuoVuibVkKk35urxiFnrBVPIcIVy0wzGO72Bn5XU3vukJ5tpcREjFgAjbGnA4 4j/LTc3t2cOhzhkm5AwfSkncgW5keDm2rqDVT0yDralCVbTCVYWHeao4FVSHWCk/lLJ8 U4rtrddLpFJWVzKFCByLcZFZe9m7k8tjINEAJfpxLN320qVRC2bkYPCy8jk8dNb8WS/W ZMzg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=XRL3tBOV+e7U/3RgUcYJnYESYC8ZAFUsbML3LdnNAI0=; fh=n8eNxIWSYJwy/CU3QSXzDvE/zeEoomCGojuOcYEQEyQ=; b=f4VDf6CxbG4DUnWX1nTL0rEZdX1OGxEZPmTyZ9lQL0NEJ3viI44sQB9E2sSmo0NnLg vdZotoTicjJ4Su66cZDoNxwVZzwHuIVIkdiXHtzSIK1zecDIIy8RwgSmHM04G6++UJNz hxpijHxJq6w9a7UKmrTH2McoazfsklJIyMsO9+9InmVaeoMtWcn1sScLcNvviQIFRXZ9 QNlNAVkyhIis8kDKLvJrZX96RlXOaOKQAxEHg7Tt/ChAevTvqpL9eLzsCmoo+qsZzG6P j/S9UtapRlIMRj4vugwRiOZvYqNdvLQqkfnGEUQuVQqHeWcJtwpHtmX7cQesIb3Zaaue xE8g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=l9MVf2ox; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from server2.sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id bs15-20020ac86f0f000000b004254fdbbd17si5197163qtb.300.2023.12.04.18.39.07 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 18:39:07 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=l9MVf2ox; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B18C63B61C0B for <ouuuleilei@gmail.com>; Tue, 5 Dec 2023 02:32:44 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 52DD83882124 for <gcc-patches@gcc.gnu.org>; Tue, 5 Dec 2023 02:31:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52DD83882124 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 52DD83882124 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701743470; cv=none; b=aWsS8tc9+z53A0TM3Iujo+IwXc49DPX4iz8GQVF2yQhzo/13s2wftYYW7vg/IHM67K8hl5GR7ZYwVjN2TtjunBJ/lSrgJWFYfzLwpCRBtkyDtvri5R2L5c3xXLikrK4kzO4m1i6lpLiLFhdwq6EpiTK8kzyFZmgx7WHrMF7tLhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701743470; c=relaxed/simple; bh=1R8R1T66Xd5tmZC/q/CB3N0p4deraFzMzBiiH5YWoV8=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=Ty9sFATxUPUFR13JR7CaoF/xDoWwH9HVcRLCAP2tzz/3iKqfCdXFkMG1Ikbc1G/81HYGbe/wz4tJi9+724B89vjRX4FL8mWAVMydqNrifRokQXajjwTR2emELgqtMyuiACHXlN1yB155fVHVR/1G/KqmdQagYZ/fXx9JrfZSIvY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mgamail.intel.com ([192.55.52.136]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <wwwhhhyyy333@gmail.com>) id 1rALD5-0001YN-UO for gcc-patches@gcc.gnu.org; Mon, 04 Dec 2023 21:30:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1701743455; x=1733279455; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=1R8R1T66Xd5tmZC/q/CB3N0p4deraFzMzBiiH5YWoV8=; b=l9MVf2oxM0OS+j5fQBwZHWmyW7gxFNGrvOdt7oXyHLAQPcbk7eRIDVqB MTbfuL+zA1Uz+/zmDA+bNeqSy+U9ynHfjO5bO8VcHOuYr9AXG1rRRfZme 8GIKtHOtQ2j+zYntpNUa2eAE2OQpNwoFJZ+SzYlAj1pT5clLUXy68nZbN JmQs9v/CqXE8NpYnu+Ht48rxjFFnajkfarbCGwMuMnAvGk2miMMTmbut8 zMMWCE7k8R1ddkUOhNyq04J5DQ84QXbYJahKn1RUGOv1C2WJ6uTHEHAfW X426XnxfjMXNDwFJsstcYaJcPILNbY++Tub21yDvg0FpY9oeg+mHyGk1M Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10914"; a="373277776" X-IronPort-AV: E=Sophos;i="6.04,251,1695711600"; d="scan'208";a="373277776" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Dec 2023 18:29:50 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10914"; a="841275489" X-IronPort-AV: E=Sophos;i="6.04,251,1695711600"; d="scan'208";a="841275489" Received: from shvmail03.sh.intel.com ([10.239.245.20]) by fmsmga004.fm.intel.com with ESMTP; 04 Dec 2023 18:29:49 -0800 Received: from shliclel4217.sh.intel.com (shliclel4217.sh.intel.com [10.239.240.127]) by shvmail03.sh.intel.com (Postfix) with ESMTP id 39F0F1005665; Tue, 5 Dec 2023 10:29:48 +0800 (CST) From: Hongyu Wang <hongyu.wang@intel.com> To: gcc-patches@gcc.gnu.org Cc: ubizjak@gmail.com, hongtao.liu@intel.com Subject: [PATCH 02/17] [APX NDD] Restrict TImode register usage when NDD enabled Date: Tue, 5 Dec 2023 10:29:33 +0800 Message-Id: <20231205022948.504790-3-hongyu.wang@intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20231205022948.504790-1-hongyu.wang@intel.com> References: <20231205022948.504790-1-hongyu.wang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: softfail client-ip=192.55.52.136; envelope-from=wwwhhhyyy333@gmail.com; helo=mgamail.intel.com X-Spam_score_int: -28 X-Spam_score: -2.9 X-Spam_bar: -- X-Spam_report: (-2.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_PASS, SPF_SOFTFAIL, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784407861193593814 X-GMAIL-MSGID: 1784407861193593814 |
Series |
Support Intel APX NDD
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | warning | Git am fail log |
Commit Message
Hongyu Wang
Dec. 5, 2023, 2:29 a.m. UTC
Under APX NDD, previous TImode allocation will have issue that it was originally allocated using continuous pair, like rax:rdi, rdi:rdx. This will cause issue for all TImode NDD patterns. For NDD we will not assume the arithmetic operations like add have dependency between dest and src1, then write to 1st highpart rdi will be overrided by the 2nd lowpart rdi if 2nd lowpart rdi have different src as input, then the write to 1st highpart rdi will missed and cause miscompliation. To resolve this, under TARGET_APX_NDD we'd only allow register with even regno to be allocated with TImode, then TImode registers will be allocated with non-overlapping pairs. There could be some error for inline assembly if it forcely allocate __int128 with odd number general register. gcc/ChangeLog: * config/i386/i386.cc (ix86_hard_regno_mode_ok): Restrict even regno for TImode if APX NDD enabled. --- gcc/config/i386/i386.cc | 10 ++++++++++ 1 file changed, 10 insertions(+)
Comments
On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang <hongyu.wang@intel.com> wrote: > > Under APX NDD, previous TImode allocation will have issue that it was > originally allocated using continuous pair, like rax:rdi, rdi:rdx. > > This will cause issue for all TImode NDD patterns. For NDD we will not > assume the arithmetic operations like add have dependency between dest > and src1, then write to 1st highpart rdi will be overrided by the 2nd > lowpart rdi if 2nd lowpart rdi have different src as input, then the write > to 1st highpart rdi will missed and cause miscompliation. > > To resolve this, under TARGET_APX_NDD we'd only allow register with even > regno to be allocated with TImode, then TImode registers will be allocated > with non-overlapping pairs. Perhaps you could use earlyclobber with __doubleword instructions: (define_insn_and_split "*add<dwi>3_doubleword" [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=ro,r") (plus:<DWI> (match_operand:<DWI> 1 "nonimmediate_operand" "%0,0") (match_operand:<DWI> 2 "x86_64_hilo_general_operand" "r<di>,o"))) (clobber (reg:CC FLAGS_REG))] For the above pattern, you can add earlyclobbered &r output alternative that guarantees that output won't be allocated to any of the input registers. Uros. > There could be some error for inline assembly if it forcely allocate __int128 > with odd number general register. > > gcc/ChangeLog: > > * config/i386/i386.cc (ix86_hard_regno_mode_ok): Restrict even regno > for TImode if APX NDD enabled. > --- > gcc/config/i386/i386.cc | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc > index 93a9cb556a5..3efeed396c4 100644 > --- a/gcc/config/i386/i386.cc > +++ b/gcc/config/i386/i386.cc > @@ -20873,6 +20873,16 @@ ix86_hard_regno_mode_ok (unsigned int regno, machine_mode mode) > return true; > return !can_create_pseudo_p (); > } > + /* With TImode we previously have assumption that src1/dest will use same > + register, so the allocation of highpart/lowpart can be consecutive, and > + 2 TImode insn would held their low/highpart in continuous sequence like > + rax:rdx, rdx:rcx. This will not work for APX_NDD since NDD allows > + different registers as dest/src1, when writes to 2nd lowpart will impact > + the writes to 1st highpart, then the insn will be optimized out. So for > + TImode pattern if we support NDD form, the allowed register number should > + be even to avoid such mixed high/low part override. */ > + else if (TARGET_APX_NDD && mode == TImode) > + return regno % 2 == 0; > /* We handle both integer and floats in the general purpose registers. */ > else if (VALID_INT_MODE_P (mode) > || VALID_FP_MODE_P (mode)) > -- > 2.31.1 >
Uros Bizjak <ubizjak@gmail.com> 于2023年12月5日周二 18:46写道: > > On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang <hongyu.wang@intel.com> wrote: > > > > Under APX NDD, previous TImode allocation will have issue that it was > > originally allocated using continuous pair, like rax:rdi, rdi:rdx. > > > > This will cause issue for all TImode NDD patterns. For NDD we will not > > assume the arithmetic operations like add have dependency between dest > > and src1, then write to 1st highpart rdi will be overrided by the 2nd > > lowpart rdi if 2nd lowpart rdi have different src as input, then the write > > to 1st highpart rdi will missed and cause miscompliation. > > > > To resolve this, under TARGET_APX_NDD we'd only allow register with even > > regno to be allocated with TImode, then TImode registers will be allocated > > with non-overlapping pairs. > > Perhaps you could use earlyclobber with __doubleword instructions: > > (define_insn_and_split "*add<dwi>3_doubleword" > [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=ro,r") > (plus:<DWI> > (match_operand:<DWI> 1 "nonimmediate_operand" "%0,0") > (match_operand:<DWI> 2 "x86_64_hilo_general_operand" "r<di>,o"))) > (clobber (reg:CC FLAGS_REG))] > > For the above pattern, you can add earlyclobbered &r output > alternative that guarantees that output won't be allocated to any of > the input registers. > Yes, it does resolve the dest/src overlapping issue we met, thanks! I tried it and no fails in gcc-testsuite and spec. Suppose for different src1/src2 RA can handle them correctly. Will update in V3 patches with the changes of get_attr_isa (insn) == ISA_APX_NDD
On Wed, Dec 6, 2023 at 2:31 AM Hongyu Wang <wwwhhhyyy333@gmail.com> wrote: > > Uros Bizjak <ubizjak@gmail.com> 于2023年12月5日周二 18:46写道: > > > > > On Tue, Dec 5, 2023 at 3:29 AM Hongyu Wang <hongyu.wang@intel.com> wrote: > > > > > > Under APX NDD, previous TImode allocation will have issue that it was > > > originally allocated using continuous pair, like rax:rdi, rdi:rdx. > > > > > > This will cause issue for all TImode NDD patterns. For NDD we will not > > > assume the arithmetic operations like add have dependency between dest > > > and src1, then write to 1st highpart rdi will be overrided by the 2nd > > > lowpart rdi if 2nd lowpart rdi have different src as input, then the write > > > to 1st highpart rdi will missed and cause miscompliation. > > > > > > To resolve this, under TARGET_APX_NDD we'd only allow register with even > > > regno to be allocated with TImode, then TImode registers will be allocated > > > with non-overlapping pairs. > > > > Perhaps you could use earlyclobber with __doubleword instructions: > > > > (define_insn_and_split "*add<dwi>3_doubleword" > > [(set (match_operand:<DWI> 0 "nonimmediate_operand" "=ro,r") > > (plus:<DWI> > > (match_operand:<DWI> 1 "nonimmediate_operand" "%0,0") > > (match_operand:<DWI> 2 "x86_64_hilo_general_operand" "r<di>,o"))) > > (clobber (reg:CC FLAGS_REG))] > > > > For the above pattern, you can add earlyclobbered &r output > > alternative that guarantees that output won't be allocated to any of > > the input registers. > > > > Yes, it does resolve the dest/src overlapping issue we met, thanks! > I tried it and no fails in gcc-testsuite and spec. Suppose for > different src1/src2 RA can handle them correctly. Yes, and when memory input operand is used in doubleword patterns, you need earlyclobber anyway, otherwise nothing prevents the compiler from clobbering address registers. When addr registers are dead, the compiler can (and will) allocate output register to the same regno as address register. Uros, > Will update in V3 patches with the changes of get_attr_isa (insn) == ISA_APX_NDD
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc index 93a9cb556a5..3efeed396c4 100644 --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -20873,6 +20873,16 @@ ix86_hard_regno_mode_ok (unsigned int regno, machine_mode mode) return true; return !can_create_pseudo_p (); } + /* With TImode we previously have assumption that src1/dest will use same + register, so the allocation of highpart/lowpart can be consecutive, and + 2 TImode insn would held their low/highpart in continuous sequence like + rax:rdx, rdx:rcx. This will not work for APX_NDD since NDD allows + different registers as dest/src1, when writes to 2nd lowpart will impact + the writes to 1st highpart, then the insn will be optimized out. So for + TImode pattern if we support NDD form, the allowed register number should + be even to avoid such mixed high/low part override. */ + else if (TARGET_APX_NDD && mode == TImode) + return regno % 2 == 0; /* We handle both integer and floats in the general purpose registers. */ else if (VALID_INT_MODE_P (mode) || VALID_FP_MODE_P (mode))