[llvm-bugs] [Bug 50468] New: [X86] X86ISelLowering combineShiftLeft contains a transform that isn't undef safe.

[via llvm-bugs]

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

            Bug ID: 50468
           Summary: [X86] X86ISelLowering combineShiftLeft contains a
                    transform that isn't undef safe.
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: craig.topper at gmail.com
                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

This function contains this transform which increases the uses of V. This isn't
correct if V is undef or could become undef later.

  // Hardware support for vector shifts is sparse which makes us scalarize the  
  // vector operations in many cases. Also, on sandybridge ADD is faster than   
  // shl.                                                                       
  // (shl V, 1) -> add V,V                                                      
  if (auto *N1BV = dyn_cast<BuildVectorSDNode>(N1))                             
    if (auto *N1SplatC = N1BV->getConstantSplatNode()) {                        
      assert(N0.getValueType().isVector() && "Invalid vector shift type");      
      // We shift all of the values by one. In many cases we do not have        
      // hardware support for this operation. This is better expressed as an
ADD                                                                             
      // of two values.                                                         
      if (N1SplatC->isOne())                                                    
        return DAG.getNode(ISD::ADD, SDLoc(N), VT, N0, N0);                     
    } 


For i16/i32/i64 we can probably just use an isel pattern instead like we do for
scalar shift left. Not sure how to preserve i8.

-- 
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/20210525/4d29ee6a/attachment.html>