[Bug rtl-optimization/109527] New: redundant register assignment

[Bug rtl-optimization/109527] New: redundant register assignment

[vanyacpp at gmail dot com]

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

            Bug ID: 109527
           Summary: redundant register assignment
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

On this function

short test(short* a)
{
    *a = 1;
    return *a;
}


latest gcc -O2 generates:

test(short*):
        mov     eax, 1
        mov     WORD PTR [rdi], ax
        mov     eax, 1
        ret

I believe the second assignment to eax is redundant and can be removed:

test(short*):
        mov     eax, 1
        mov     WORD PTR [rdi], ax
        ret

[Bug target/109527] redundant register assignment

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2023-04-15
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Take:
```
short test(int t, short* a)
{
    *a = 1;
    return *a;
}
```
This produces decent code for aarch64:
```
        mov     w0, 1
        strh    w0, [x1]
        ret
```


Note I suspect this is really does not show up that often either and only
happens with return values.

[Bug target/109527] redundant register assignment

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|X86_64                      |x86_64-*-*

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We get here from

        movw    $1, (%rdi)
        movl    $1, %eax

via a peephole2:

+Splitting with gen_peephole2_162 (i386.md:23103)
...
-    6: [di:DI]=0x1
-      REG_DEAD di:DI
+   22: ax:HI=0x1
+   23: [di:DI]=ax:HI
    11: ax:HI=0x1
    12: use ax:HI

there's no later CSE that would optimize this (maybe the peephole2 pass
could fire CSE on each [E]BB a peephole2 triggers?).

The reason for this transform is LCP stalls on Core2/CoreiX which is
also done when tuning for generic.  -mtune-ctrl=^lcp_stall retains
the immediate move.