[Bug rtl-optimization/86352] setc/movzx introduced into loop to provide a constant 0 value for a later rep stos

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-08-29
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note GCC does too good of a job and removes the zeroing of the return value as
it is not used; it actually removes the return value fully :).

Here is a new testcase which does not cause the removal of the zeroing.
    using u64 = unsigned long long;

    struct Bucket {
        u64 mLeaves[16] = {};
    };

    struct BucketMap {
        u64 acquire() noexcept {
            while (true) {
                u64 map = mData;

                u64 index = (map & 1) ? 1 : 0;
                auto mask = u64(1) << index;

                auto previous =
                    __atomic_fetch_or(&mData, mask, __ATOMIC_SEQ_CST);
                if ((previous & mask) == 0) {
                    return index;
                }
            }
        }

        __attribute__((noinline)) Bucket acquireBucket() noexcept {
            acquire();
            return Bucket();
        }

        volatile u64 mData = 1;
    };

    int main() {
        BucketMap map;
        Bucket t = map.acquireBucket();
        return t.mLeaves[0];
    }

With the trunk we get:
BucketMap::acquireBucket():
.LFB1:
        .cfi_startproc
        movq    %rdi, %r8
        movq    %rsi, %rcx
        .p2align 4,,10
        .p2align 3
.L2:
        movq    (%rsi), %rdx
        xorl    %eax, %eax
        andl    $1, %edx
        lock btsq       %rdx, (%rcx)
        setc    %al
        jc      .L2
        movq    %r8, %rdi
        movl    $16, %ecx
        rep stosq
        movq    %r8, %rax
        ret

So the setc is useless overall really.
The reason why it is still there is because it does not become useless until
after combine and the dce for RTL runs right before combine.

Trying 14, 17 -> 18:
   14: r93:DI=flags:CCC==0
      REG_DEAD flags:CCC
   17: flags:CCZ=cmp(r93:DI,0)
   18: pc={(flags:CCZ!=0)?L16:pc}
      REG_DEAD flags:CCZ
      REG_BR_PROB 955630228
Failed to match this instruction:
(parallel [
        (set (pc)
            (if_then_else (eq (reg:CCC 17 flags)
                    (const_int 0 [0]))
                (label_ref:DI 16)
                (pc)))
        (set (reg:DI 93)
            (eq:DI (reg:CCC 17 flags)
                (const_int 0 [0])))
    ])
Failed to match this instruction:
(parallel [
        (set (pc)
            (if_then_else (eq (reg:CCC 17 flags)
                    (const_int 0 [0]))
                (label_ref:DI 16)
                (pc)))
        (set (reg:DI 93)
            (eq:DI (reg:CCC 17 flags)
                (const_int 0 [0])))
    ])
Successfully matched this instruction:
(set (reg:DI 93)
    (eq:DI (reg:CCC 17 flags)
        (const_int 0 [0])))
Successfully matched this instruction:
(set (pc)
    (if_then_else (eq (reg:CCC 17 flags)
            (const_int 0 [0]))
        (label_ref:DI 16)
        (pc)))
allowing combination of insns 14, 17 and 18
original costs 4 + 4 + 12 = 20
replacement costs 4 + 12 = 16
deferring deletion of insn with uid = 14.
modifying insn i2    17: r93:DI=flags:CCC==0
deferring rescan insn with uid = 17.
modifying insn i3    18: pc={(flags:CCC==0)?L16:pc}
      REG_BR_PROB 955630228
      REG_DEAD flags:CCZ
deferring rescan insn with uid = 18.

The reason reg 93 was not REG_DEAD after if statement is because cse and/or
forwprop (and maybe even gcse) cames around and decides to that it r93 should
be reused for 0 outside of the loop.
Maybe if frowprop could do better with set/cmp/if in the first place, this
might not have happened ...
Just some good things leading to bad code and too much interactions to count
here.

Also as I said the original testcase GCC now optimizes better anyways (better
than LLVM even).