From patchwork Thu Aug 22 09:16:28 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Kyrill Tkachov X-Patchwork-Id: 1151399 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-507497-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="b5kUq4QB"; 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 46Df6h1hp7z9s7T for ; Thu, 22 Aug 2019 19:16:41 +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:to:cc :from:subject:message-id:date:mime-version:content-type; q=dns; s=default; b=Wuhbhzw/TUIiMYJRi03VEt+UsMBwSb2Ag/5AbT4Py3s2CURgYa GgU6ykTKqg0DplDIxiVTYOWYGJDjgoXokGoDgSRoGGpHJ6BBLfT3jYPYanbWVgXg dhDcu/sIzP8VF234mUNY6fpuWLhZLNwX12s9hVw/54IH76iJ7xlQG7Ywo= 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:to:cc :from:subject:message-id:date:mime-version:content-type; s= default; bh=c3edM9DjeOWmZDE/AGS2FFtIako=; b=b5kUq4QBkjl85+8/WFFm HCt/Jg16BeXSGC3pZFe7d9mbj8rQC//eAodnCbQUbgZWMjbcmkd4G9Zh8cQe0TFM xt4GtNiXhq79qAzQmtV2wkvIc8Dc3gdf8wNalsA39mFtQeWvwsdyZ5GoN0YddyV7 l4rgvaza31EoHsqlmomtoZo= Received: (qmail 33611 invoked by alias); 22 Aug 2019 09:16:33 -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 33602 invoked by uid 89); 22 Aug 2019 09:16:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-17.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=pain, destinations X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Aug 2019 09:16:31 +0000 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 EFCD1360; Thu, 22 Aug 2019 02:16:29 -0700 (PDT) Received: from [10.2.206.47] (e120808-lin.cambridge.arm.com [10.2.206.47]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6050B3F246; Thu, 22 Aug 2019 02:16:29 -0700 (PDT) To: "gcc-patches@gcc.gnu.org" Cc: Richard Earnshaw , James Greenhalgh , Marcus Shawcroft From: Kyrill Tkachov Subject: [PATCH][AArch64] Don't split 64-bit constant stores to volatile location Message-ID: Date: Thu, 22 Aug 2019 10:16:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 Hi all, The optimisation to optimise:    typedef unsigned long long u64;    void bar(u64 *x)    {      *x = 0xabcdef10abcdef10;    } from:         mov     x1, 61200         movk    x1, 0xabcd, lsl 16         movk    x1, 0xef10, lsl 32         movk    x1, 0xabcd, lsl 48         str     x1, [x0] into:         mov     w1, 61200         movk    w1, 0xabcd, lsl 16         stp     w1, w1, [x0] ends up producing two distinct stores if the destination is volatile:   void bar(u64 *x)   {     *(volatile u64 *)x = 0xabcdef10abcdef10;   }         mov     w1, 61200         movk    w1, 0xabcd, lsl 16         str     w1, [x0]         str     w1, [x0, 4] because we end up not merging the strs into an stp. It's questionable whether the use of STP is valid for volatile in the first place. To avoid unnecessary pain in a context where it's unlikely to be performance critical [1] (use of volatile), this patch avoids this transformation for volatile destinations, so we produce the original single STR-X. Bootstrapped and tested on aarch64-none-linux-gnu. Ok for trunk (and eventual backports)? Thanks, Kyrill [1] https://lore.kernel.org/lkml/20190821103200.kpufwtviqhpbuv2n@willie-the-truck/ gcc/ 2019-08-22  Kyrylo Tkachov     * config/aarch64/aarch64.md (mov): Don't call     aarch64_split_dimode_const_store on volatile MEM. gcc/testsuite/ 2019-08-22  Kyrylo Tkachov     * gcc.target/aarch64/nosplit-di-const-volatile_1.c: New test. diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 753c7978700d441c71cf97d5ae1e11f160b270af..cb91da796b3e9bfd6f19e714ccee7791b9cf3714 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -1108,8 +1108,8 @@ (match_operand:GPI 1 "general_operand"))] "" " - if (MEM_P (operands[0]) && CONST_INT_P (operands[1]) - && mode == DImode + if (MEM_P (operands[0]) && !MEM_VOLATILE_P (operands[0]) + && CONST_INT_P (operands[1]) && mode == DImode && aarch64_split_dimode_const_store (operands[0], operands[1])) DONE; diff --git a/gcc/testsuite/gcc.target/aarch64/nosplit-di-const-volatile_1.c b/gcc/testsuite/gcc.target/aarch64/nosplit-di-const-volatile_1.c new file mode 100644 index 0000000000000000000000000000000000000000..da5975ad1652c00a3b69b3dc19e5c09c77526de7 --- /dev/null +++ b/gcc/testsuite/gcc.target/aarch64/nosplit-di-const-volatile_1.c @@ -0,0 +1,15 @@ +/* Check that storing the 64-bit immediate to a volatile location is done + with a single store. */ + +/* { dg-do compile } */ +/* { dg-options "-O2" } */ + +typedef unsigned long long u64; + +void bar (u64 *x) +{ + *(volatile u64 *)x = 0xabcdef10abcdef10ULL; +} + +/* { dg-final { scan-assembler-times "str\tx..?, .*" 1 } } */ +/* { dg-final { scan-assembler-not "str\tw..?, .*" } } */