[Bug target/110184] New: [i386] Missed optimisation: atomic operations should use PF, ZF and SF

["thiago at kde dot org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 110184
           Summary: [i386] Missed optimisation: atomic operations should
                    use PF, ZF and SF
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thiago at kde dot org
  Target Milestone: ---

Follow up from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566

The x86 locked ALU operations always set PF, ZF and SF, so the atomic builtins
could use those to emit more optimal code instead of a cmpxchg loop.

Given:
template <auto Op> int atomic_rmw_op(std::atomic_int &i)
{
    int old = Op(i);
    if (old == 0)
        return 1;
    if (old < 0)
        return 2;
    return 0;
}

-------
Starting with the non-standard __atomic_OP_fetch, the current code for 

inline int andn_fetch_1(std::atomic_int &i)
{
    return __atomic_and_fetch((int *)&i, ~1, 0);
}

is

L33:
        movl    %eax, %edx
        andl    $-2, %edx
        lock cmpxchgl   %edx, (%rdi)
        jne     .L33
        movl    %edx, %eax
        shrl    $31, %eax
        addl    %eax, %eax      // eax = 2 if edx < 0
        testl   %edx, %edx
        movl    $1, %edx
        cmove   %edx, %eax

But it could be more optimally written as:

        movl    %ecx, 1
        movl    %edx, 2
        xorl    %eax, %eax
        lock andl    $-2, (%rdi)
        cmove   %ecx, %eax
        cmovs   %edx, %eax

The other __atomic_OP_fetch operations are very similar. I note that GCC
already realises that if you perform __atomic_and_fetch(ptr, 1), the result
can't have the sign bit set.

-------
For the standard atomic_fetch_OP operations, there are a couple of caveats:

fetch_and: if the retrieved value is ANDed again with the same pattern; for
example:
    int pattern = 0x80000001;
    return i.fetch_and(pattern, std::memory_order_relaxed) & pattern;
This appears to be partially implemented, depending on what the pattern is. For
example, it generates the optimal code for pattern = 3, 15, 0x7fffffff,
0x80000000. It appears to be related to testing for either SF or ZF, but not
both.

fetch_or: always for SF, for the useful case when the pattern being ORed
doesn't already contain the sign bit. If it does (a "non-useful case"), then
the comparison is a constant, and likewise for ZF because it's never set if the
pattern isn't zero.

fetch_xor: always, because the original value is reconstructible. Avoid
generating unnecessary code in case the code already does the XOR itself, as
in:

    return i.fetch_xor(1, std::memory_order_relaxed) ^ 1;


See https://gcc.godbolt.org/z/n9bMnaE4e for full results.