LLVM 13 regression: lost transformation x < C && y < C && z < C to (x | y | z) < C

[Quuxplusone]

Bugzilla Link	PR51745
Status	NEW
Importance	P enhancement
Reported by	David Bolvansky (david.bolvansky@gmail.com)
Reported on	2021-09-04 02:30:24 -0700
Last modified on	2021-09-05 11:23:38 -0700
Version	trunk
Hardware	PC Linux
CC	llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, nikita.ppv@gmail.com, nok.raven@gmail.com, spatel+llvm@rotateright.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also	PR51577

x < C && y < C && z < C to  (x | y | z) < C  where C is power of two.

bool
src1 (unsigned x, unsigned y, unsigned z, unsigned w)
{
  return x < 1024 && y < 1024 && z < 1024 && w < 1024;
}

bool
tgt1 (unsigned x, unsigned y, unsigned z, unsigned w)
{
  return (x | y | z | w) < 1024;
}

GCC:
src1(unsigned int, unsigned int, unsigned int, unsigned int):
        or      edx, ecx
        or      edx, esi
        or      edx, edi
        cmp     edx, 1023
        setbe   al
        ret
tgt1(unsigned int, unsigned int, unsigned int, unsigned int):
        or      edx, ecx
        or      edx, esi
        or      edx, edi
        cmp     edx, 1023
        setbe   al
        ret

Clang trunk:
src1(unsigned int, unsigned int, unsigned int, unsigned int):
# @src1(unsigned int, unsigned int, unsigned int, unsigned int)
        cmp     edi, 1024
        setb    al
        cmp     esi, 1024
        setb    sil
        and     sil, al
        cmp     edx, 1024
        setb    dl
        cmp     ecx, 1024
        setb    al
        and     al, dl
        and     al, sil
        ret
tgt1(unsigned int, unsigned int, unsigned int, unsigned int):
# @tgt1(unsigned int, unsigned int, unsigned int, unsigned int)
        or      edi, esi
        or      edx, ecx
        or      edx, edi
        cmp     edx, 1024
        setb    al
        ret

Regressed with LLVM 13 which disabled select-to-or optimization.

[Quuxplusone]

Looks very similar to bug 51577

[Quuxplusone]

I don't think this fold should be performed in the middle end at all, as it breaks canonical comparison structure. I'm handling this special pattern in LVI, but many other places reasoning about conditions don't.

We should fold this in DAG instead.