[Bug target/99773] New: ARM v8.1-m MVE interaction with -mfloat-abi not clear

[Bug target/99773] New: ARM v8.1-m MVE interaction with -mfloat-abi not clear

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

            Bug ID: 99773
           Summary: ARM v8.1-m MVE interaction with -mfloat-abi not clear
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

I noticed an unexpected linker error when compiling with
-march=armv8.1-m.main+mve -mfloat-abi=hard -mcpu=cortex-m55 -mthumb
error: /tmp/ccQvvmcJ.o uses VFP register arguments, ./XXX.exe does not

Using mve.fp instead of mve fixes that.

However, I'm used to -mfloat-abi=hard defining the eabi attribute:
Tag_ABI_VFP_args: VFP registers

Compiling
===================================
typedef int __attribute((vector_size(16))) v4si;

float g(float x, float y)
{
    x += y;
    return x;
}

v4si f(v4si x, v4si y)
{
    return x + y;
}
===================================
with -O2 -march=armv8.1-m.main+mve -mfloat-abi=hard
generates for f:
        vadd.i32  q0, q0, q1
        bx      lr
which uses the MVE registers for the parameters, but the object files does not
have the Tag_ABI_VFP_args: VFP registers attribute I would expect.

It does have
Tag_MVE_arch: MVE Integer only
is that enough?

Is the current behavior expected or is there a bug?

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

--- Comment #1 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
-march=armv8.1-m.main+mve -mfloat-abi=hard should use the VFP registers for
passing any FP arguments so the build attribute for Tag_ABI_VFP_args should be
set to show that.

It's true that soft-float routines will still be needed to do any FP operations
in this case, but that doesn't affect the ABI at public interfaces.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-03-25
     Ever confirmed|0                           |1

--- Comment #2 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Confirmed, then.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

--- Comment #3 from Christophe Lyon <clyon at gcc dot gnu.org> ---
I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
#define TARGET_HARD_FLOAT_SUB   (arm_float_abi != ARM_FLOAT_ABI_SOFT    \
                                 && (bitmap_bit_p (arm_active_target.isa, \
                                                  isa_bit_vfpv2) \
                                    || bitmap_bit_p (arm_active_target.isa, \
                                                     isa_bit_mve))      \
                                 && TARGET_32BIT)

but that has other implications, like enabing VFP patterns: for instance
mulsf3_vfp becomes enabled, leading to a failure when builing libgcc (vmul.f32
is generated for powisf2, but rejected by the assembler)

So maybe we just change the condition to emit the attributes in arm_file_start?

Something like:
      if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
        {
          if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
            arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);

          if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
            arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
        }

but that does not look very clean

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to Christophe Lyon from comment #3)
> I tried changing TARGET_HARD_FLOAT_SUB in arm.h to:
> #define TARGET_HARD_FLOAT_SUB   (arm_float_abi != ARM_FLOAT_ABI_SOFT    \
>                                  && (bitmap_bit_p (arm_active_target.isa, \
>                                                   isa_bit_vfpv2) \
>                                     || bitmap_bit_p (arm_active_target.isa, \
>                                                      isa_bit_mve))      \
>                                  && TARGET_32BIT)
> 
> but that has other implications, like enabing VFP patterns: for instance
> mulsf3_vfp becomes enabled, leading to a failure when builing libgcc
> (vmul.f32 is generated for powisf2, but rejected by the assembler)
> 
> So maybe we just change the condition to emit the attributes in
> arm_file_start?
> 
> Something like:
>       if (! TARGET_SOFT_FLOAT || TARGET_HAVE_MVE)
>         {
>           if ((TARGET_HARD_FLOAT && TARGET_VFP_SINGLE) || TARGET_HAVE_MVE)
>             arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);
> 
>           if (TARGET_HARD_FLOAT_ABI || TARGET_HAVE_MVE)
>             arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);
>         }
> 

It doesn't look right, either.  Why would you want to set Tag_ABI_HardFP_use to
1 when there's no single-precision only FPU present?


Untested, but I think something like

      if (TARGET_HARD_FLOAT && TARGET_VFP_SINGLE)
        arm_emit_eabi_attribute ("Tag_ABI_HardFP_use", 27, 1);

      if (TARGET_HARD_FLOAT_ABI)
        arm_emit_eabi_attribute ("Tag_ABI_VFP_args", 28, 1);

is probably the right solution, removing the ! TARGET_SOFT_FLOAT entirely.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

--- Comment #5 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Compiling with -march=armv8.1-m.main+mve -mfloat-abi=hard defines:
TARGET_SOFT_FLOAT 1
TARGET_HARD_FLOAT 0
TARGET_HARD_FLOAT_ABI 1
TARGET_VFP_SINGLE 1

so indeed what you propose does the trick.

(Sorry I proposed comment #3 yesterday too in a hurry)

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Christophe Lyon <clyon@gcc.gnu.org>:

https://gcc.gnu.org/g:6f93a7c7fc62b2d6ab47e5d5eb60d41366e1ee9e

commit r11-7908-g6f93a7c7fc62b2d6ab47e5d5eb60d41366e1ee9e
Author: Christophe Lyon <christophe.lyon@linaro.org>
Date:   Tue Mar 30 12:26:33 2021 +0000

    arm: Fix emission of Tag_ABI_VFP_args with MVE and -mfloat-abi=hard (PR
target/99773)

    When compiling with -mfloat-abi=hard -march=armv8.1-m.main+mve, we
    want to emit Tag_ABI_VFP_args even though we are not emitting
    floating-point instructions (we need "+mve.fp" for that), because we
    use MVE registers to pass FP arguments.

    This patch removes the condition on (! TARGET_SOFT_FLOAT) because this
    is a case where TARGET_SOFT_FLOAT is true, and TARGET_HARD_FLOAT_ABI
    is true too.

    2021-03-30  Richard Earnshaw  <rearnsha@arm.com>

            gcc/
            PR target/99773
            * config/arm/arm.c (arm_file_start): Fix emission of
            Tag_ABI_VFP_args attribute.

[Bug target/99773] ARM v8.1-m MVE interaction with -mfloat-abi not clear

[clyon at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99773

Christophe Lyon <clyon at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Christophe Lyon <clyon at gcc dot gnu.org> ---
Fixed