[llvm-bugs] [Bug 48215] New: [X86][AVX] Attempt to share broadcasts of different widths (D57663) - node/value mismatch

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48215

            Bug ID: 48215
           Summary: [X86][AVX] Attempt to share broadcasts of different
                    widths (D57663) - node/value mismatch
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm-dev at redking.me.uk
                CC: craig.topper at gmail.com, llvm-bugs at lists.llvm.org,
                    llvm-dev at redking.me.uk, pengfei.wang at intel.com,
                    spatel+llvm at rotateright.com

We've discovered a problem with an old patch D57663:

    // Share broadcast with the longest vector and extract low subvector
(free).
    for (SDNode *User : Src->uses())
      if (User != N.getNode() && User->getOpcode() == X86ISD::VBROADCAST &&
          User->getValueSizeInBits(0) > VT.getSizeInBits()) {
        return extractSubVector(SDValue(User, 0), 0, DAG, DL,
                                VT.getSizeInBits());
      }

We're only ensuring the source is from the same SDNode, but not checking its
from the same SDValue. So if we're broadcasting from different values from the
same node (e.g. a ISD::SDIVREM node) then we could match with the wrong
broadcast.

This manually created test case shows the problem:

define i32 @broadcast_sdiv_srem(i32 %a0, i32 %a1)  {
  %d = sdiv i32 %a0, %a1
  %r = srem i32 %a0, %a1
  %dv0 = insertelement <8 x i32> undef, i32 %d, i32 0
  %rv0 = insertelement <4 x i32> undef, i32 %r, i32 0
  %dv1 = shufflevector <8 x i32> %dv0, <8 x i32> undef, <8 x i32>
zeroinitializer
  %rv1 = shufflevector <4 x i32> %rv0, <4 x i32> undef, <4 x i32>
zeroinitializer
  %dc0 = icmp slt <8 x i32> %dv1, <i32 0, i32 1, i32 2, i32 3, i32 4, i32 5,
i32 6, i32 7>
  %rc0 = icmp slt <4 x i32> %rv1, <i32 4, i32 5, i32 6, i32 7>
  %db0 = bitcast <8 x i1> %dc0 to i8
  %rb0 = bitcast <4 x i1> %rc0 to i4
  %db1 = zext i8 %db0 to i32
  %rb1 = zext i4 %rb0 to i32
  %res = add i32 %db1, %rb1
  ret i32 %res
}

We can see the issue here, on a AVX1 target we broadcast (via PSHUFD) both
values:

        idivl   %esi
        vmovd   %edx, %xmm0
        vpshufd $0, %xmm0, %xmm0                # xmm0 = xmm0[0,0,0,0]
        vpcmpgtd        %xmm0, %xmm1, %xmm0
        vmovd   %eax, %xmm2
        vmovmskps       %xmm0, %eax
        vpshufd $0, %xmm2, %xmm2                # xmm2 = xmm2[0,0,0,0]
        vpcmpgtd        %xmm2, %xmm1, %xmm3
        vpcmpgtd        %xmm2, %xmm4, %xmm2
        vinsertf128     $1, %xmm3, %ymm2, %ymm2
        vmovmskps       %ymm2, %ecx
        addl    %ecx, %eax
        retq

But on a AVX2 target which performs the fold we end up with a single broadcast:

        idivl   %esi
        vmovd   %eax, %xmm0 # WHERE DID THE %edx BROADCAST GO?
        vpbroadcastd    %xmm0, %ymm0
        vpcmpgtd        %ymm0, %ymm1, %ymm1
        vpcmpgtd        %xmm0, %xmm2, %xmm0
        vmovmskps       %ymm1, %ecx
        vmovmskps       %xmm0, %eax
        addl    %ecx, %eax
        vzeroupper
        retq

https://gcc.godbolt.org/z/fWf4Es

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201118/9c70bf81/attachment.html>