From patchwork Fri Feb 19 10:53:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Andre Vieira (lists)" X-Patchwork-Id: 1442081 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=nUT4IVWE; dkim-atps=neutral Received: from sourceware.org (unknown [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DhpN74qsDz9sRR for ; Fri, 19 Feb 2021 21:53:42 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BF2AF398B160; Fri, 19 Feb 2021 10:53:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BF2AF398B160 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1613732019; bh=MKpp5ecisXBIf1+RlC10UZXgMjIIbKetduCZy2qi8Sk=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=nUT4IVWEbxWiAnApIAInFTyafHmfkC+Trykna2wnUrsY5/UW05MychL7tTC22DpH4 a7MYm1aOY8m6N8T3OJejm40Je5TJmm73yWkJz14JJ9cbWfKY1xdmvgy8J3jMTUf31o M7SzNr9fpu+n7mky2kXLzG+GR1nB0x22R2eZryKw= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 1F33F3846403 for ; Fri, 19 Feb 2021 10:53:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1F33F3846403 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9CE09ED1; Fri, 19 Feb 2021 02:53:36 -0800 (PST) Received: from [10.57.12.138] (unknown [10.57.12.138]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 347B03F694; Fri, 19 Feb 2021 02:53:36 -0800 (PST) To: "gcc-patches@gcc.gnu.org" Subject: [PATCH][PR98791]: IRA: Make sure allocno copy mode's are ordered Message-ID: <0637fdd9-f396-57e5-ed4f-4d54594020c9@arm.com> Date: Fri, 19 Feb 2021 10:53:22 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 Content-Language: en-US X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00, BODY_8BITS, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: "Andre Vieira \(lists\) via Gcc-patches" From: "Andre Vieira (lists)" Reply-To: "Andre Vieira \(lists\)" Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" Hi, This patch makes sure that allocno copies are not created for unordered modes. The testcases in the PR highlighted a case where an allocno copy was being created for: (insn 121 120 123 11 (parallel [             (set (reg:VNx2QI 217)                 (vec_duplicate:VNx2QI (subreg/s/v:QI (reg:SI 93 [ _2 ]) 0)))             (clobber (scratch:VNx16BI))         ]) 4750 {*vec_duplicatevnx2qi_reg}      (expr_list:REG_DEAD (reg:SI 93 [ _2 ])         (nil))) As the compiler detected that the vec_duplicate_reg pattern allowed the input and output operand to be of the same register class, it tried to create an allocno copy for these two operands, stripping subregs in the process. However, this meant that the copy was between VNx2QI and SI, which have unordered mode precisions. So at compile time we do not know which of the two modes is smaller which is a requirement when updating allocno copy costs. Regression tested on aarch64-linux-gnu. Is this OK for trunk (and after a week backport to gcc-10) ? Regards, Andre gcc/ChangeLog: 2021-02-19  Andre Vieira          PR rtl-optimization/98791         * ira-conflicts.c (process_regs_for_copy): Don't create allocno copies for unordered modes. gcc/testsuite/ChangeLog: 2021-02-19  Andre Vieira          PR rtl-optimization/98791         * gcc.target/aarch64/sve/pr98791.c: New test. diff --git a/gcc/ira-conflicts.c b/gcc/ira-conflicts.c index 2c2234734c3166872d94d94c5960045cb89ff2a8..d83cfc1c1a708ba04f5e01a395721540e31173f0 100644 --- a/gcc/ira-conflicts.c +++ b/gcc/ira-conflicts.c @@ -275,7 +275,10 @@ process_regs_for_copy (rtx reg1, rtx reg2, bool constraint_p, ira_allocno_t a1 = ira_curr_regno_allocno_map[REGNO (reg1)]; ira_allocno_t a2 = ira_curr_regno_allocno_map[REGNO (reg2)]; - if (!allocnos_conflict_for_copy_p (a1, a2) && offset1 == offset2) + if (!allocnos_conflict_for_copy_p (a1, a2) + && offset1 == offset2 + && ordered_p (GET_MODE_PRECISION (ALLOCNO_MODE (a1)), + GET_MODE_PRECISION (ALLOCNO_MODE (a2)))) { cp = ira_add_allocno_copy (a1, a2, freq, constraint_p, insn, ira_curr_loop_tree_node); diff --git a/gcc/testsuite/gcc.target/aarch64/sve/pr98791.c b/gcc/testsuite/gcc.target/aarch64/sve/pr98791.c new file mode 100644 index 0000000000000000000000000000000000000000..ee0c7b51602cacd45f9e33acecb1eaa9f9edebf2 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/sve/pr98791.c @@ -0,0 +1,12 @@ +/* PR rtl-optimization/98791 */ +/* { dg-do compile } */ +/* { dg-options "-O -ftree-vectorize --param=aarch64-autovec-preference=3" } */ +extern char a[], b[]; +short c, d; +long *e; +void f() { + for (int g; g < c; g += 1) { + a[g] = d; + b[g] = e[g]; + } +}