[llvm-bugs] [Bug 46983] New: [SLP] Failure to account for truncating stores in MinVF calculation

[via llvm-bugs]

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

            Bug ID: 46983
           Summary: [SLP] Failure to account for truncating stores in
                    MinVF calculation
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: llvm-dev at redking.me.uk
                CC: a.bataev at hotmail.com, anton.a.afanasyev at gmail.com,
                    llvm-bugs at lists.llvm.org
            Blocks: 46968

Noticed while investigating [Bug #46968]

https://godbolt.org/z/T9Mna8

The MinVF calculation in SLPVectorizerPass::vectorizeStoreChain is based off
the 
number of storesize elements that fix in the vector register:

const unsigned MinVF = R.getMinVecRegSize() / Sz;

But this means we fail to account for cases where we are truncating the result
just prior to the store.

Sz is set by:

unsigned BoUpSLP::getVectorElementSize(Value *V) {
  // If V is a store, just return the width of the stored value without
  // traversing the expression tree. This is the common case.
  if (auto *Store = dyn_cast<StoreInst>(V))
    return DL->getTypeSizeInBits(Store->getValueOperand()->getType());

  ...
}

So we may be able to just check for truncates feeding stores in the StoreInst
case.


Referenced Bugs:

https://bugs.llvm.org/show_bug.cgi?id=46968
[Bug 46968] Missed SLP vectorization with umin/umax
-- 
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/20200804/47915cd3/attachment.html>