[Bug target/111876] New: aarch64: Wrong code for bf16 complex mul/div when the target has +fp16 support.

[Bug target/111876] New: aarch64: Wrong code for bf16 complex mul/div when the target has +fp16 support.

[iains at gcc dot gnu.org]

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

            Bug ID: 111876
           Summary: aarch64: Wrong code for bf16 complex mul/div when the
                    target has +fp16 support.
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

this is somewhat similar to PR111867, but in this case the issue seems to
happen at expand time.

---- reduced from "bfloat16-complex.c"

volatile __bf16 a = 1.0bf16;
typedef _Complex float __cbf16 __attribute__((__mode__(__BC__)));
volatile __cbf16 b = __builtin_complex (2.0bf16, 3.0bf16);

int main (void)
{
  volatile __cbf16 r ;
  r = a + b;
  r *= r;
  return 0;
}

----

For -march=armv8.4-a+fp16

This lowers to calls to (non-existent libgcc) ___mulbc3 (and __divbc3, when
division is included).

For -march=armv8.4-a

This promotes the bf16 -> float and calls __mulsc3 (which exists)

[Bug target/111876] aarch64: bf16 complex mul/div does not work when the target has +fp16 support.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2023-10-19
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
            Summary|aarch64: Wrong code for     |aarch64: bf16 complex
                   |bf16 complex mul/div when   |mul/div does not work when
                   |the target has +fp16        |the target has +fp16
                   |support.                    |support.

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This could either be wrong code for not doing the promotion or just missing the
libgcc functions (which could be implemented as doing the promotion).

Either ways confirmed.

[Bug target/111876] aarch64: bf16 complex mul/div does not work when the target has +fp16 support.

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> This could either be wrong code for not doing the promotion or just missing
> the libgcc functions (which could be implemented as doing the promotion).
> 
> Either ways confirmed.

thanks, for checking.
but I think the underlying concern is that providing a disjoint extension
(+fp16) should not alter the behaviour of bf16 (in this case I did some limited
poking about but could not see any obvious place where the addition of fp16
alters complex number handling).

[Bug target/111876] aarch64: bf16 complex mul/div does not work when the target has +fp16 support.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This could either be wrong code for not doing the promotion or just missing
> > the libgcc functions (which could be implemented as doing the promotion).
> > 
> > Either ways confirmed.
> 
> thanks, for checking.
> but I think the underlying concern is that providing a disjoint extension
> (+fp16) should not alter the behaviour of bf16 (in this case I did some
> limited poking about but could not see any obvious place where the addition
> of fp16 alters complex number handling).

The difference comes from the front-end which adds the promotions even.

[Bug target/111876] aarch64: bf16 complex mul/div does not work when the target has +fp16 support or when -fexcess-precision=16 is supplied

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|aarch64                     |aarch64 x86_64
            Summary|aarch64: bf16 complex       |aarch64: bf16 complex
                   |mul/div does not work when  |mul/div does not work when
                   |the target has +fp16        |the target has +fp16
                   |support.                    |support or when
                   |                            |-fexcess-precision=16 is
                   |                            |supplied
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So the difference between with/without +fp16 is -fexcess-precision=16 vs
without that option.

On x86_64 with -fexcess-precision=16, we get the same link failure.
Maybe Jakub understands what is the correct behavior here; (since he added
bfloat16 support to x86_64; r13-3292-gc2565a31c1622ab0926aeef4a6579413e121b9f9
).

[Bug target/111876] bf16 complex mul/div does not work when the target has +fp16 support or when -fexcess-precision=16 is supplied

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
for the record an __fp16 implementation works as expected;

* when the target does not support +fp16, the code-gen promotes to float and
does the multiply with __mulsc3

* when the target supports +fp16, the code-gen uses __mulhc3 (which is
implemented in libgcc)

* adding "+bf16" does not affect this.

---

So the issue is that __bf16 works when there is no support for a 16b float,
(because, like fp16, it gets promoted) - but fails when the target declares
support for a different 16 float.

[Bug middle-end/111876] bf16 complex mul/div does not work when the target has +fp16 support or when -fexcess-precision=16 is supplied

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end
           Keywords|                            |testsuite-fail

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I see this failure with `-march=armv9-a+sve2` .

Just for record it is while testing:
FAIL: gcc.dg/torture/bfloat16-complex.c   -O0  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O0  compilation failed to
produce executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -O1  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O1  compilation failed to
produce executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -O2  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O2  compilation failed to
produce executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  compilation failed to produce
executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -O3 -g  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -O3 -g  compilation failed to
produce executable
FAIL: gcc.dg/torture/bfloat16-complex.c   -Os  (test for excess errors)
UNRESOLVED: gcc.dg/torture/bfloat16-complex.c   -Os  compilation failed to
produce executable