From patchwork Thu Apr 9 16:51:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 1268686 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=2620:52:3:1:0:246e:9693:128c; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=arm.com Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (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 48ynGR0ld1z9sSq for ; Fri, 10 Apr 2020 02:51:09 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E2B64385BF81; Thu, 9 Apr 2020 16:51:04 +0000 (GMT) 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 3F614385B835 for ; Thu, 9 Apr 2020 16:51:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3F614385B835 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=richard.sandiford@arm.com 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 E309031B for ; Thu, 9 Apr 2020 09:51:01 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 89D433F73D for ; Thu, 9 Apr 2020 09:51:01 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: [committed, wwwdocs] aarch64: Document SVE changes Date: Thu, 09 Apr 2020 17:51:00 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-Spam-Status: No, score=-26.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, 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: , Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" As per $SUBJECT This seemed to flow more naturally if we organised things as: - improvements to existing features - new options - new extensions - new CPUs The patch also fixes up some missing tags flagged by xmllint. Pushed. --- htdocs/gcc-10/changes.html | 100 +++++++++++++++++++++++++++++++------ 1 file changed, 85 insertions(+), 15 deletions(-) diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 1c8d7a9f..61c767f4 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -237,6 +237,7 @@ a work-in-progress.

with the new attribute access. +

C

@@ -336,6 +337,7 @@ a work-in-progress.

causing an syntactic ambiguity. +
  • G++ can now detect modifying constant objects in constexpr evaluation (which is undefined behavior). @@ -452,6 +454,7 @@ a work-in-progress.

    For formatted input/output, if the explicit widths after the data-edit descriptors I, F and G have been omitted, default widths are used. +
  • A blank format item at the end of a format specification, i.e. nothing following the final comma, is allowed. Use the option @@ -478,6 +481,7 @@ a work-in-progress.

    CHARACTER expressions. Use the option -fdec.
    • +
  • Character type names in errors and warnings now include len in addition to kind; * is used for assumed @@ -516,38 +520,104 @@ a work-in-progress.

    AArch64

      -
    • The -mbranch-protection=pac-ret option now accepts the +
    • There have been several improvements related to the Scalable + Vector Extension (SVE): +
        +
      • The SVE ACLE types and intrinsics are now supported. They can + be accessed using the header file arm_sve.h. +
        • +
      • It is now possible to create fixed-length SVE types using + the arm_sve_vector_bits attribute. For example: +
        #if __ARM_FEATURE_SVE_BITS==512
+typedef svint32_t vec512 __attribute__((arm_sve_vector_bits(512)));
+typedef svbool_t pred512 __attribute__((arm_sve_vector_bits(512)));
+#endif
        +
        • +
      • -mlow-precision-div, -mlow-precision-sqrt + and -mlow-precision-recip-sqrt now work for SVE. +
        • +
      • -msve-vector-bits=128 now generates + vector-length-specific code for little-endian targets. It continues + to generate vector-length-agnostic code for big-endian targets, + just as previous releases did for all targets. +
        • +
      • The vectorizer is now able to use extending loads and truncating + stores, including gather loads and scatter stores. +
        • +
      • The vectorizer now compares the cost of vectorizing with SVE + and vectorizing with Advanced SIMD and tries to pick the best one. + Previously it would always use SVE if possible. +
        • +
      • If a vector loop uses Advanced SIMD rather than SVE, the vectorizer + now considers using SVE to vectorize the left-over elements (the + “scalar tail” or “epilog”). +
        • +
      • Besides these specific points, there have been many general + improvements to the way that the vectorizer uses SVE. +
        • +
      +
      • +
    • The -mbranch-protection=pac-ret option now accepts the optional argument +b-key extension to perform return address signing with the B-key instead of the A-key.
      • +
    • The option -moutline-atomics has been added to aid + deployment of the Large System Extensions (LSE) on GNU/Linux systems built + with a baseline architecture targeting Armv8-A. When the option is + specified code is emitted to detect the presence of LSE instructions at + runtime and use them for standard atomic operations. + For more information please refer to the documentation. +
    • The Transactional Memory Extension is now supported through ACLE intrinsics. It can be enabled through the +tme option extension (for example, -march=armv8.5-a+tme).
      • -
    • Initial autovectorization support for SVE2 has been added and can be - enabled through the +sve2 option extension (for example, - -march=armv8.5-a+sve2). Additional extensions can be enabled - through +sve2-sm4, +sve2=aes, - +sve2-sha3, +sve2-bitperm. -
      • -
    • A number of features from the Armv8.5-a are now supported through ACLE +
    • A number of features from Armv8.5-A are now supported through ACLE intrinsics. These include:
      • The random number instructions that can be enabled through the (already present in GCC 9.1) +rng option extension.
      • Floating-point intrinsics to round to integer instructions from - Armv8.5-a when targeting -march=armv8.5-a or later.
        • + Armv8.5-A when targeting -march=armv8.5-a or later.
      • Memory Tagging Extension intrinsics enabled through the +memtag option extension.
      • -
    • The option -moutline-atomics has been added to aid - deployment of the Large System Extensions (LSE) on GNU/Linux systems built - with a baseline architecture targeting Armv8-A. When the option is - specified code is emitted to detect the presence of LSE instructions at - runtime and use them for standard atomic operations. - For more information please refer to the documentation. +
    • Similarly, the following Armv8.6-A features are now supported + through ACLE intrinsics: +
        +
      • The bfloat16 extension. This extension is enabled automatically + when Armv8.6-A is selected (such as by -march=armv8.6-a). + It can also be enabled for Armv8.2-A and later using the + +bf16 option extension. +
        • +
      • The Matrix Multiply extension. This extension is split into + three parts, one for each supported data type: +
          +
        • Support for 8-bit integer matrix multiply instructions. + This extension is enabled automatically when Armv8.6-A is + selected. It can also be enabled for Armv8.2-A and later using + the +i8mm option extension. +
          • +
        • Support for 32-bit floating-point matrix multiply instructions. + This extension can be enabled using the +f32mm + option extension, which also has the effect of enabling SVE. +
          • +
        • Support for 64-bit floating-point matrix multiply instructions. + This extension can be enabled using the +f64mm + option extension, which likewise has the effect of enabling SVE. +
          • +
        +
        • +
      +
      • +
    • SVE2 is now supported through ACLE intrinsics and (to a limited extent) + through autovectorization. It can be enabled through the +sve2 + option extension (for example, -march=armv8.5-a+sve2). + Additional extensions can be enabled through +sve2-sm4, + +sve2=aes, +sve2-sha3 and + +sve2-bitperm.
    • Support has been added for the following processors