From patchwork Wed Jul 3 03:33:47 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stafford Horne X-Patchwork-Id: 1126594 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-504237-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="ahHSaoLX"; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="K4MC61gi"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 45dmtp5kGtz9s4V for ; Wed, 3 Jul 2019 13:34:26 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; q=dns; s=default; b=aa+ diLq1WP2P8I1ZrxQpiHl1iwNW47zVzmqJPuxLE3TsTEIuinyoRnV5K5xWhuyEncZ NccD1sIbf5SyKArdApXjySV6s0BrQwGsyaYpx+euUypcSrUIg7x5anuVg3DzgGtr xAsYKiVsgSngSgF6aEb+CBbomAyU9ew87wuynW6Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; s=default; bh=e9cJSolYi 61+55xF6vbAvfnlhVs=; b=ahHSaoLXWB3Jb47XRuLtV5gU68UMcNyMAi0oFwj50 feWWU4dfk94QS1sFj7Zvi7xauEh+hSKQhfIEhsFJlm+34BNSOdAA4uCVQJfoXceM HCLJJlud14XgqorjzBaPPx6plCcig0Maa2JqcQAmmJPc7qq9ADCC2iqkKQn/jSHy wI= Received: (qmail 38341 invoked by alias); 3 Jul 2019 03:34:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 38267 invoked by uid 89); 3 Jul 2019 03:34:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=5.3.0, borrowed X-HELO: mail-pl1-f176.google.com Received: from mail-pl1-f176.google.com (HELO mail-pl1-f176.google.com) (209.85.214.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Jul 2019 03:34:07 +0000 Received: by mail-pl1-f176.google.com with SMTP id 9so415229ple.5 for ; Tue, 02 Jul 2019 20:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=l2i6w6zvTuJiDQUvgJSAzrj7k+pLRsy0FIOccOj7CXY=; b=K4MC61gi/d3Aa3NMntAkWy0NT1x1aEeQUkGEiKXMSHm55PNMDR0Zyntpm3wYjHDIh/ dUsL/YCG7/3tIy0DABtk8YuSrjqZE/HStk5ORgdYjbr8J2s1fMdrA6GNK0L/PYKwQH7U 0Xkzo2wkz6jiMn151CWrT7KI4OChPga41h/SYKisHlrIKLB6tIGZoydUprflIzMuX5Ss Ql1xVO6mHzfDuhLZD1OO5S0ZezrHY8in8nO/tpBUU19Zb16n238AMLMJseUxnazYYCD+ LaJz+xQTlA11vX5g1spEPhP4fdVR8VsKJEQbbz3dF/EI1qNQPDVCtfaqJLQR6GBumxBi 6IdA== Received: from localhost (g223.61-115-60.ppp.wakwak.ne.jp. [61.115.60.223]) by smtp.gmail.com with ESMTPSA id w22sm527972pfi.175.2019.07.02.20.34.04 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 02 Jul 2019 20:34:05 -0700 (PDT) From: Stafford Horne To: GCC patches Cc: Openrisc , Bernhard Reutner-Fischer , Jeff Law , Stafford Horne Subject: [PATCH v2 1/5] or1k: Fix code quality for volatile memory loads Date: Wed, 3 Jul 2019 12:33:47 +0900 Message-Id: <20190703033351.11924-2-shorne@gmail.com> In-Reply-To: <20190703033351.11924-1-shorne@gmail.com> References: <20190703033351.11924-1-shorne@gmail.com> MIME-Version: 1.0 X-IsSubscribed: yes Volatile memory does not match the memory_operand predicate. This causes extra extend/mask instructions instructions when reading from volatile memory. On OpenRISC loading volatile memory can be treated the same as regular memory loads which supports combined sign/zero extends. Fixing this eliminates the need for extra extend/mask instructions. This also adds a test provided by Richard Selvaggi which uncovered the issue while we were looking into another issue. gcc/ChangeLog: PR target/90363 * config/or1k/or1k.md (zero_extendsi2): Update predicate. (extendsi2): Update predicate. * gcc/config/or1k/predicates.md (volatile_mem_operand): New. (reg_or_mem_operand): New. gcc/testsuite/ChangeLog: PR target/90363 * gcc.target/or1k/swap-1.c: New test. * gcc.target/or1k/swap-2.c: New test. --- Since v1: - Fixed typos with volatile gcc/config/or1k/or1k.md | 6 +-- gcc/config/or1k/predicates.md | 18 +++++++ gcc/testsuite/gcc.target/or1k/swap-1.c | 70 ++++++++++++++++++++++++++ gcc/testsuite/gcc.target/or1k/swap-2.c | 47 +++++++++++++++++ 4 files changed, 138 insertions(+), 3 deletions(-) create mode 100644 gcc/testsuite/gcc.target/or1k/swap-1.c create mode 100644 gcc/testsuite/gcc.target/or1k/swap-2.c diff --git a/gcc/config/or1k/or1k.md b/gcc/config/or1k/or1k.md index 2dad51cd46b..757d899c442 100644 --- a/gcc/config/or1k/or1k.md +++ b/gcc/config/or1k/or1k.md @@ -328,11 +328,11 @@ ;; Sign Extending ;; ------------------------------------------------------------------------- -;; Zero extension can always be done with AND and an extending load. +;; Zero extension can always be done with AND or an extending load. (define_insn "zero_extendsi2" [(set (match_operand:SI 0 "register_operand" "=r,r") - (zero_extend:SI (match_operand:I12 1 "nonimmediate_operand" "r,m")))] + (zero_extend:SI (match_operand:I12 1 "reg_or_mem_operand" "r,m")))] "" "@ l.andi\t%0, %1, @@ -344,7 +344,7 @@ (define_insn "extendsi2" [(set (match_operand:SI 0 "register_operand" "=r,r") - (sign_extend:SI (match_operand:I12 1 "nonimmediate_operand" "r,m")))] + (sign_extend:SI (match_operand:I12 1 "reg_or_mem_operand" "r,m")))] "TARGET_SEXT" "@ l.exts\t%0, %1 diff --git a/gcc/config/or1k/predicates.md b/gcc/config/or1k/predicates.md index 879236bca49..b895f1b4228 100644 --- a/gcc/config/or1k/predicates.md +++ b/gcc/config/or1k/predicates.md @@ -82,3 +82,21 @@ (define_predicate "equality_comparison_operator" (match_code "ne,eq")) + +;; Borrowed from rs6000 +; Return true if the operand is in volatile memory. Note that during the +;; RTL generation phase, memory_operand does not return TRUE for volatile +;; memory references. So this function allows us to recognize volatile +;; references where it's safe. +(define_predicate "volatile_mem_operand" + (and (match_code "mem") + (match_test "MEM_VOLATILE_P (op)") + (if_then_else (match_test "reload_completed") + (match_operand 0 "memory_operand") + (match_test "memory_address_p (mode, XEXP (op, 0))")))) + +;; Return true if the operand is a register or memory; including volatile +;; memory. +(define_predicate "reg_or_mem_operand" + (ior (match_operand 0 "nonimmediate_operand") + (match_operand 0 "volatile_mem_operand"))) diff --git a/gcc/testsuite/gcc.target/or1k/swap-1.c b/gcc/testsuite/gcc.target/or1k/swap-1.c new file mode 100644 index 00000000000..4c179d1e430 --- /dev/null +++ b/gcc/testsuite/gcc.target/or1k/swap-1.c @@ -0,0 +1,70 @@ +/* { dg-do run } */ +/* { dg-options "-Os -mhard-mul -msoft-div -msoft-float" } */ + +/* Notes: + + This test failed on or1k GCC 7.2.0, and passes on or1k GCC 5.3.0 + as well as the or1k port released in GCC 9.1. + + The main program is organized as a loop structure so gcc does not + optimize-away the calls to swap_1(). Compiling with -O2 is still smart + enough to optimize-away the calls, but using -Os does not. + The bad code is only generated when compiled with -Os. + + When the bad code is generated all code is okay except for the very last + instruction (a 'l.addc' in the l.jr delay slot). + Up to that point in execution, r11 and r12 contain the correct (expected) + values, but the execution of the final "l.addc" corrupts r11. + + This test is added to ensure this does not come back. */ + +#include + +volatile static uint8_t g_doswap = 1; + +uint64_t swap_1 (uint64_t u64) { + uint32_t u64_lo, u64_hi, u64_tmp; + + u64_lo = u64 & 0xFFFFFFFF; + u64_hi = u64 >> 32; + + if (g_doswap) + { + u64_tmp = u64_lo; + u64_lo = u64_hi; + u64_hi = u64_tmp; + } + + u64 = u64_lo; + u64 += ((uint64_t) u64_hi << 32); + + return u64; +} + +int main () { + int ret; + int iter; + uint64_t aa[2]; // inputs to swap function + uint64_t ee[2]; // expected outputs of swap function + uint64_t rr[2]; // actual results of swap function + + g_doswap = 1; + + // populate inputs, and expected outputs: + aa[0] = 0x123456789abcdef0; + aa[1] = 0x0123456789abcdef; + + ee[0] = 0x9ABCDEF012345678; + ee[1] = 0x89ABCDEF01234567; + + ret = 0; + for (iter = 0; iter < 2; iter++) + { + rr[iter] = swap_1(aa[iter]); + // early-out if there's a mis-match: + if (ee[iter] != rr[iter]) + ret = 1; + } + + return ret; +} diff --git a/gcc/testsuite/gcc.target/or1k/swap-2.c b/gcc/testsuite/gcc.target/or1k/swap-2.c new file mode 100644 index 00000000000..3730b4ee2e3 --- /dev/null +++ b/gcc/testsuite/gcc.target/or1k/swap-2.c @@ -0,0 +1,47 @@ +/* { dg-do compile } */ +/* { dg-options "-Os -mhard-mul -msoft-div -msoft-float" } */ + +/* Notes: + + This test failed on or1k GCC 7.2.0, and passes on or1k GCC 5.3.0 + as well as the or1k port released in GCC 9.1. + + The main program is organized as a loop structure so gcc does not + optimize-away the calls to swap_1(). Compiling with -O2 is still smart + enough to optimize-away the calls, but using -Os does not. + The bad code is only generated when compiled with -Os. + + When the bad code is generated all code is okay except for the very last + instruction (a 'l.addc' in the l.jr delay slot). + Up to that point in execution, r11 and r12 contain the correct (expected) + values, but the execution of the final "l.addc" corrupts r11. + + This test ensures an l.addc is not in the output. Also, while confirming + this test we uncovered PR/90363, we use it to check for that as well. */ + +#include + +volatile static uint8_t g_doswap = 1; + +uint64_t swap_1 (uint64_t u64) { + uint32_t u64_lo, u64_hi, u64_tmp; + + u64_lo = u64 & 0xFFFFFFFF; + u64_hi = u64 >> 32; + + if (g_doswap) + { + u64_tmp = u64_lo; + u64_lo = u64_hi; + u64_hi = u64_tmp; + } + + u64 = u64_lo; + u64 += ((uint64_t) u64_hi << 32); + + return u64; +} + +/* Check to ensure the volatile load does not get zero extended. */ +/* { dg-final { scan-assembler-not "0xff" } } */ +/* { dg-final { scan-assembler-not "l.addc" } } */