[Bug c++/107208] New: [aarch64] llvm generate better code than gcc base on _Complex type mul

[Bug c++/107208] New: [aarch64] llvm generate better code than gcc base on _Complex type mul

[zhongyunde at huawei dot com]

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

            Bug ID: 107208
           Summary: [aarch64] llvm generate better code than gcc base on
                    _Complex type mul
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* gcc now generate 2 redundant mov instrunction compared to llvm
```
mul64(unsigned long _Complex, unsigned long _Complex):
        mov     x4, x1    // redundant ??
        mov     x5, x0    // redundant ??
        mul     x6, x1, x2
        mul     x2, x0, x2
        madd    x1, x5, x3, x6
        msub    x0, x4, x3, x2
        ret
```

* test case, https://godbolt.org/z/EWE3bc5b3
```
unsigned long _Complex mul64 (unsigned long _Complex mul0,
                              unsigned long _Complex mul1)
{
    return mul0 * mul1;
}
```

[Bug rtl-optimization/107208] [aarch64] llvm generate better code than gcc base on _Complex type mul

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
           Keywords|                            |missed-optimization
          Component|c++                         |rtl-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely this is a register allocation issue. I suspect it is due to the way
incoming and returns are represented for complex integer types.

Note complex integer types are an extension to the c language so I doubt many
people use them anyways.

[Bug middle-end/107208] [aarch64] _complex integer return types could be improved

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[aarch64] llvm generate     |[aarch64] _complex integer
                   |better code than gcc base   |return types could be
                   |on _Complex type mul        |improved
          Component|rtl-optimization            |middle-end
   Last reconfirmed|                            |2022-10-11
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Yes it is due to return value and how it is done:

(insn 32 28 33 2 (clobber (reg/i:CDI 0 x0)) "/app/example.cpp":6:1 -1
     (nil))
(insn 33 32 34 2 (set (reg:DI 0 x0)
        (reg:DI 102 [ <retval> ])) "/app/example.cpp":6:1 -1
     (nil))
(insn 34 33 35 2 (set (reg:DI 1 x1 [+8 ])
        (reg:DI 103 [ <retval>+8 ])) "/app/example.cpp":6:1 -1
     (nil))
(insn 35 34 0 2 (use (reg/i:CDI 0 x0)) "/app/example.cpp":6:1 -1
     (nil))


So this is not _Complex integer multiplies at all but rather just the return
values and the register allocator.

I wonder why Complex float is expanded slightly differently (and better here):

(insn 34 33 35 2 (set (reg:SF 32 v0)
        (reg:SF 115)) "/app/example.cpp":6:1 -1
     (nil))
(insn 35 34 36 2 (set (reg:SF 33 v1)
        (reg:SF 118)) "/app/example.cpp":6:1 -1
     (nil))
(insn 36 35 37 2 (use (reg:SF 32 v0)) "/app/example.cpp":6:1 -1
     (nil))
(insn 37 36 0 2 (use (reg:SF 33 v1)) "/app/example.cpp":6:1 -1
     (nil))

Who chose CDI for the integer case but a pair of SF for the float case ...

[Bug middle-end/107208] [aarch64] _complex integer return types could be improved

[zhongyunde at huawei dot com]

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

--- Comment #3 from vfdff <zhongyunde at huawei dot com> ---
it seems releted to targetm.calls.function_value called by assign_parms, who
return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
the following changes, then choose a pair of DI for the int case
```
@@ -20333,7 +20333,7 @@ aarch64_vfp_is_call_or_return_candidate (machine_mode
mode,
       *count = 1;
       new_mode = mode;
     }
-  else if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
+  else if (COMPLEX_MODE_P (mode))

```

[Bug middle-end/107208] [aarch64] _complex integer return types could be improved

[rearnsha at gcc dot gnu.org]

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

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
(In reply to vfdff from comment #3)
> it seems releted to targetm.calls.function_value called by assign_parms, who
> return different behaviour for MODE_COMPLEX_FLOAT and MODE_COMPLEX_INT. With
> the following changes, then choose a pair of DI for the int case
> ```
> @@ -20333,7 +20333,7 @@ aarch64_vfp_is_call_or_return_candidate
> (machine_mode mode,
>        *count = 1;
>        new_mode = mode;
>      }
> -  else if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT)
> +  else if (COMPLEX_MODE_P (mode))
> 
> ```

This can't be right.  aarch64_vfp_is_call_or_return_candidate is for VFP/SIMD
arguments and complex int is not one of those.