[Bug c/105495] New: `__atomic_compare_exchange` prevents tail-call optimization

[Bug c/105495] New: `__atomic_compare_exchange` prevents tail-call optimization

[lh_mouse at 126 dot com]

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

            Bug ID: 105495
           Summary: `__atomic_compare_exchange` prevents tail-call
                    optimization
           Product: gcc
           Version: 11.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

Godbolt: https://gcc.godbolt.org/z/7ob6zc17P

Offending testcase:

```c
typedef struct { int b; } cond;

int
__MCF_batch_release_common(cond* p, int c);

int
_MCF_cond_signal_some(cond* p, int x)
  {
    cond c = {x}, n = {2};
    __atomic_compare_exchange(p, &c, &n, 1, 0, 0);
    return __MCF_batch_release_common(p, x);
  }
```


GCC output:

```asm
_MCF_cond_signal_some:
        sub     rsp, 24
        mov     edx, 2
        mov     eax, esi
        mov     DWORD PTR [rsp+12], esi
        lock cmpxchg    DWORD PTR [rdi], edx
        je      .L2
        mov     DWORD PTR [rsp+12], eax      <------- note this extra store,
which clang doesn't generate
.L2:
        call    __MCF_batch_release_common
        add     rsp, 24
        ret
```


Clang output:

```asm
_MCF_cond_signal_some:                  # @_MCF_cond_signal_some
        mov     ecx, 2
        mov     eax, esi
        lock            cmpxchg dword ptr [rdi], ecx
        jmp     __MCF_batch_release_common      # TAILCALL
```

1. If `cond` was defined as a scalar type such as `long`, there is no such
issue.
2. `__atomic_exchange` doesn't suffer from this issue.

[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization

[lh_mouse at 126 dot com]

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

--- Comment #1 from LIU Hao <lh_mouse at 126 dot com> ---
A possible workaround is to use a scalar type to provide storage for local
variables, and cast them as needed:

Godbolt: https://gcc.godbolt.org/z/n7zq7Pn4G

```c
typedef struct { int b; } cond;

int
__MCF_batch_release_common(cond* p, int c);

int
_MCF_cond_signal_some(cond* p, int x)
  {
    int c = {x}, n = {2};
    __atomic_compare_exchange((cond*)p, (cond*)&c, (cond*)&n, 1, 0, 0);
    return __MCF_batch_release_common(p, x);
  }
```

This makes GCC output the same assembly as Clang.

[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-05-05
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is that we pass the 2nd argument by reference which causes a stack
slot to be allocated for 'c':

  c.b = x_2(D);
  __atomic_compare_exchange_4 (p_4(D), &c, 2, 1, 0, 0);

[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization

[lh_mouse at 126 dot com]

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

--- Comment #3 from LIU Hao <lh_mouse at 126 dot com> ---
Wouldn't that go away if the value in it is never read back?

[Bug c/105495] `__atomic_compare_exchange` prevents tail-call optimization

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The reason why it works in #c1 is that we replace the
  c = x_4(D);
  n_6 = 2;
  n.0_1 = n_6;
  n.1_2 = (unsigned int) n.0_1;
  __atomic_compare_exchange_4 (p_7(D), &c, n.1_2, 1, 0, 0);
call in the IL with:
  c_20 = x_4(D);
  _15 = c_20;
  _16 = VIEW_CONVERT_EXPR<unsigned int>(_15);
  _17 = .ATOMIC_COMPARE_EXCHANGE (p_7(D), _16, 2, 260, 0, 0);
  _18 = REALPART_EXPR <_17>;
  _19 = VIEW_CONVERT_EXPR<int>(_18);
  c_21 = _19;
during ccp1 pass, optimizing away the addressables.
But we don't do that for aggregates with sizes of integer types,
but supposedly we could do that too.

[Bug middle-end/105495] `__atomic_compare_exchange` prevents tail-call optimization

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
          Component|c                           |middle-end

[Bug middle-end/105495] `__atomic_compare_exchange` prevents tail-call optimization

[lh_mouse at 126 dot com]

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

--- Comment #5 from LIU Hao <lh_mouse at 126 dot com> ---
This does not trigger the issue:

```c
#define __atomic_compare_exchange(p,c,n,w,ms,mf)  \
  ({ int __temp;  \
     __builtin_memcpy(&__temp, c, sizeof(*c));  \
     _Bool __r = __atomic_compare_exchange(p, (__typeof__(*(c))*) &__temp, n,
w, ms, mf);  \
     __builtin_memcpy(c, &__temp, sizeof(*c));  \
     __r;  });

typedef struct { int b; } cond;

int
__MCF_batch_release_common(cond* p, int c);

int
_MCF_cond_signal_some(cond* p, int x)
  {
    cond c = {x}, n = {2};
    __atomic_compare_exchange(p, &c, &n, 1, 0, 0);
    return __MCF_batch_release_common(p, x);
  }
```

which results in (godbolt https://gcc.godbolt.org/z/n68T1c6oP):

```asm
_MCF_cond_signal_some:
        mov     edx, 2
        mov     eax, esi
        lock cmpxchg    DWORD PTR [rdi], edx
        jmp     __MCF_batch_release_common
```

Effectively, we are using a `int` to provide storage for a struct of
`sizeof(int)`.

But if we use a `long` to provide storage for the struct, such issue reappears:

```c
#define __atomic_compare_exchange(p,c,n,w,ms,mf)  \
  ({ long __temp;  \
     __builtin_memcpy(&__temp, c, sizeof(*c));  \
     _Bool __r = __atomic_compare_exchange(p, (__typeof__(*(c))*) &__temp, n,
w, ms, mf);  \
     __builtin_memcpy(c, &__temp, sizeof(*c));  \
     __r;  });

typedef struct { int b; } cond;

int
__MCF_batch_release_common(cond* p, int c);

int
_MCF_cond_signal_some(cond* p, int x)
  {
    cond c = {x}, n = {2};
    __atomic_compare_exchange(p, &c, &n, 1, 0, 0);
    return __MCF_batch_release_common(p, x);
  }
```

which results in (https://gcc.godbolt.org/z/PGof8nGd7)

```asm
_MCF_cond_signal_some:
        mov     edx, 2
        mov     eax, esi
        mov     DWORD PTR [rsp-16], esi
        lock cmpxchg    DWORD PTR [rdi], edx
        je      .L2
        mov     DWORD PTR [rsp-16], eax
.L2:
        jmp     __MCF_batch_release_common
```

It is also notable that with this kind of hacks, GCC is finally able to perform
TCO on the return statement.

[Bug tree-optimization/105495] `__atomic_compare_exchange` prevents tail-call optimization

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |tree-optimization

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I wonder if we could add some access attribute such that the 2nd argument of
__atomic_compare_exchange_4 is marked as read only ...