public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon.oss@gmail.com>
To: Richard Earnshaw <rearnsha@arm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [committed v2 3/3] arm: reorder assembler architecture directives [PR101723]
Date: Fri, 6 Aug 2021 16:21:21 +0200	[thread overview]
Message-ID: <CAKhMtS+oU=oFSEa4-cfQBoLBN+-kDb6BsH1+wXO5DvbPWmWs5Q@mail.gmail.com> (raw)
In-Reply-To: <CAKhMtSK0sHV5fzat+Znz1YT1-2sc3RLw8_6jFtP1Fh4AE2X4mQ@mail.gmail.com>

On Fri, Aug 6, 2021 at 4:08 PM Christophe Lyon <
christophe.lyon.oss@gmail.com> wrote:

>
>
> On Thu, Aug 5, 2021 at 1:58 PM Richard Earnshaw <rearnsha@arm.com> wrote:
>
>>
>> A change to the way gas interprets the .fpu directive in binutils-2.34
>> means that issuing .fpu will clear any features set by .arch_extension
>> that apply to the floating point or simd units.  This unfortunately
>> causes problems for more recent versions of the architecture because
>> we currently emit .arch, .arch_extension and .fpu directives at
>> different times and try to suppress redundant changes.
>>
>> This change addresses this by firstly unifying all the places where we
>> emit these directives to a single block of code and secondly
>> (re)emitting all the directives if any changes have been made to the
>> target options.  Whilst this is slightly more than the strict minimum
>> it should be enough to catch all cases where a change could have
>> happened.  The new code also emits the directives in the order: .arch,
>> .fpu, .arch_extension.  This ensures that the additional architectural
>> extensions are not removed by a later .fpu directive.
>>
>> Whilst writing this patch I also noticed that in the corner case where
>> the last function to be compiled had a non-standard set of
>> architecture flags, the assembler would add an incorrect set of
>> derived attributes for the file as a whole.  Instead of reflecting the
>> command-line options it would reflect the flags from the last file in
>> the function.  To address this I've also added a call to re-emit the
>> flags from the asm_file_end callback so the assembler will be in the
>> correct state when it finishes processing the intput.
>>
>> There's some slight churn to the testsuite as a consequence of this,
>> because previously we had a hack to suppress emitting a .fpu directive
>> for one specific case, but with the new order this is no-longer
>> necessary.
>>
>> gcc/ChangeLog:
>>
>>         PR target/101723
>>         * config/arm/arm-cpus.in (generic-armv7-a): Add quirk to suppress
>>         writing .cpu directive in asm output.
>>         * config/arm/arm.c (arm_identify_fpu_from_isa): New variable.
>>         (arm_last_printed_arch_string): Delete.
>>         (arm_last-printed_fpu_string): Delete.
>>         (arm_configure_build_target): If use of floating-point/SIMD is
>>         disabled, remove all fp/simd related features from the target ISA.
>>         (last_arm_targ_options): New variable.
>>         (arm_print_asm_arch_directives): Add new parameters.  Change order
>>         of emitted directives and handle all cases here.
>>         (arm_file_start): Always call arm_print_asm_arch_directives, move
>>         all generation of .arch/.arch_extension here.
>>         (arm_file_end): Call arm_print_asm_arch.
>>         (arm_declare_function_name): Call arm_print_asm_arch_directives
>>         instead of printing .arch/.fpu directives directly.
>>
>> gcc/testsuite/ChangeLog:
>>
>>         PR target/101723
>>         * gcc.target/arm/cortex-m55-nofp-flag-hard.c: Update expected
>> output.
>>         * gcc.target/arm/cortex-m55-nofp-flag-softfp.c: Likewise.
>>         * gcc.target/arm/cortex-m55-nofp-nomve-flag-softfp.c: Likewise.
>>         * gcc.target/arm/mve/intrinsics/mve_fpu1.c: Convert to dg-do
>> assemble.
>>         Add a non-no-op function body.
>>         * gcc.target/arm/mve/intrinsics/mve_fpu2.c: Likewise.
>>         * gcc.target/arm/pr98636.c (dg-options): Add -mfloat-abi=softfp.
>>         * gcc.target/arm/attr-neon.c: Tighten scan-assembler tests.
>>         * gcc.target/arm/attr-neon2.c: Use -Ofast, convert test to use
>>         check-function-bodies.
>>         * gcc.target/arm/attr-neon3.c: Likewise.
>>         * gcc.target/arm/pr69245.c: Tighten scan-assembler match, but
>> allow
>>         multiple instances.
>>         * gcc.target/arm/pragma_fpu_attribute.c: Likewise.
>>         * gcc.target/arm/pragma_fpu_attribute_2.c: Likewise.
>>
>
>
> Hi Richard,
>
> There were a couple of typos in the tests updates, fixed as follows:
>
>  Author: Christophe Lyon <christophe.lyon@foss.st.com>
> Date:   Fri Aug 6 14:06:44 2021 +0000
>
>     arm: Fix typos for reorder assembler architecture directives [PR101723]
>
>     Two tests had typos preventing them from passing, committed as obvious.
>
>     2021-08-06  Christophe Lyon  <christophe.lyon@foss.st.com>
>
>             gcc/testsuite/
>             PR target/101723
>             * gcc.target/arm/attr-neon3.c: Fix typo.
>             * gcc.target/arm/pragma_fpu_attribute_2.c: Fix typo.
>
> diff --git a/gcc/testsuite/gcc.target/arm/attr-neon3.c
> b/gcc/testsuite/gcc.target/arm/attr-neon3.c
> index 0fbce6e4cd4..b6171e72d89 100644
> --- a/gcc/testsuite/gcc.target/arm/attr-neon3.c
> +++ b/gcc/testsuite/gcc.target/arm/attr-neon3.c
> @@ -33,7 +33,7 @@ my (float32x2_t __a, float32x2_t __b)
>  ** |
>  **     vld1.64 {d[0-9]+}, \[r[0-9]+:64\]!
>  **     vld1.64 {d[0-9]+}, \[r[0-9]+:64\]
> -** }
> +** )
>  **     ...
>  **     bx      lr
>  */
> diff --git a/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c
> b/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c
> index 3d33b04b787..398d8fff35c 100644
> --- a/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c
> +++ b/gcc/testsuite/gcc.target/arm/pragma_fpu_attribute_2.c
> @@ -28,5 +28,5 @@ uint32_t restored ()
>  /* We can't tell exactly how many times the following tests will match
> because
>     command-line options may cause additional instances to be generated,
> but
>     each must be present at least once.  */
> -/* { dg-final { scan-assembler-times {\.fpu\s+vfpv4\n} } } */
> -/* { dg-final { scan-assembler-times {\.fpu\s+vfpv3-d16\n} } } */
> +/* { dg-final { scan-assembler {\.fpu\s+vfpv4\n} } } */
> +/* { dg-final { scan-assembler {\.fpu\s+vfpv3-d16\n} } } *
>
> Christophe
>
>
>

Hi Richard,

There is an additional fallout:

 In gcc.target/arm/pr69245.c, to have a .fpu neon-vfpv4 directive, make




sure code for fn1() is emitted, by removing the static keyword.









Fix a typo in gcc.target/arm/pr69245.c, where \s should be \\s.














2021-08-06  Christophe Lyon  <christophe.lyon@foss.st.com>









        gcc/testsuite/









        PR target/101723




        * gcc.target/arm/pr69245.c: Make sure to emit code for fn1, fix
typo.








diff --git a/gcc/testsuite/gcc.target/arm/pr69245.c
b/gcc/testsuite/gcc.target/arm/pr69245.c



index 34b97a22e15..58a6104e8f6 100644




--- a/gcc/testsuite/gcc.target/arm/pr69245.c




+++ b/gcc/testsuite/gcc.target/arm/pr69245.c




@@ -12,7 +12,7 @@
 #pragma GCC target "fpu=neon-vfpv4"




 int a, c, d;




 float b;




-static int fn1 ()




+ int fn1 ()




 {




   return 0;




 }




@@ -26,5 +26,5 @@ void fn2 ()
 /* Because we don't know the exact command-line options used to invoke the
test



    we cannot expect these tests to match exactly once.  But they must
appear at



    least once.  */




-/* { dg-final { scan-assembler "\.fpu\s+vfp\n" } } */




-/* { dg-final { scan-assembler "\.fpu\s+neon-vfpv4\n" } } */




+/* { dg-final { scan-assembler "\.fpu\\s+vfp\n" } } */




+/* { dg-final { scan-assembler "\.fpu\\s+neon-vfpv4\n" } } */





OK?

Christophe


>
>
>> ---
>>  gcc/config/arm/arm-cpus.in                    |   1 +
>>  gcc/config/arm/arm.c                          | 186 ++++++++----------
>>  gcc/testsuite/gcc.target/arm/attr-neon.c      |   9 +-
>>  gcc/testsuite/gcc.target/arm/attr-neon2.c     |  35 ++--
>>  gcc/testsuite/gcc.target/arm/attr-neon3.c     |  48 +++--
>>  .../arm/cortex-m55-nofp-flag-hard.c           |   2 +-
>>  .../arm/cortex-m55-nofp-flag-softfp.c         |   2 +-
>>  .../arm/cortex-m55-nofp-nomve-flag-softfp.c   |   2 +-
>>  .../gcc.target/arm/mve/intrinsics/mve_fpu1.c  |   5 +-
>>  .../gcc.target/arm/mve/intrinsics/mve_fpu2.c  |   5 +-
>>  gcc/testsuite/gcc.target/arm/pr69245.c        |   6 +-
>>  gcc/testsuite/gcc.target/arm/pr98636.c        |   3 +-
>>  .../gcc.target/arm/pragma_fpu_attribute.c     |   7 +-
>>  .../gcc.target/arm/pragma_fpu_attribute_2.c   |   7 +-
>>  14 files changed, 169 insertions(+), 149 deletions(-)
>>
>>

  reply	other threads:[~2021-08-06 14:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 11:57 [committed v2 0/3] arm: fix problems when targetting extended FPUs [PR101723] Richard Earnshaw
2021-08-05 11:57 ` [committed v2 1/3] arm: ensure the arch_name is always set for the build target Richard Earnshaw
2021-08-05 11:57 ` [committed v2 2/3] arm: Don't reconfigure globals in arm_configure_build_target Richard Earnshaw
2021-08-05 11:57 ` [committed v2 3/3] arm: reorder assembler architecture directives [PR101723] Richard Earnshaw
2021-08-06 14:08   ` Christophe Lyon
2021-08-06 14:21     ` Christophe Lyon [this message]
2021-08-06 14:28       ` Richard Earnshaw
2021-08-06 14:43         ` Christophe Lyon
2021-08-06 14:25     ` Richard Earnshaw
2021-08-09 17:47     ` Christophe Lyon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKhMtS+oU=oFSEa4-cfQBoLBN+-kDb6BsH1+wXO5DvbPWmWs5Q@mail.gmail.com' \
    --to=christophe.lyon.oss@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rearnsha@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).