[PATCH] D106399: [VectorCombine] Widening of partial vector loads

Roman Lebedev via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 20 14:40:55 PDT 2021


lebedev.ri created this revision.
lebedev.ri added reviewers: spatel, RKSimon, fhahn.
lebedev.ri added a project: LLVM.
Herald added a subscriber: hiraditya.
lebedev.ri requested review of this revision.

If we are loading some vector, and we know it will be legalized into a vector,
and occupy (potentially a number of) vector registers, iff we load less bytes
than the total size of the occupied vector registers, then the legalization
will have a hard time. At worst, the load will be scalarized,
scalar vector elements inserted forming the narrow vector.

But sometimes, if the vector will be widened, we can tell that we are allowed
to load those extra 'padding' elements, based on dereferenceability or alignment knowledge.

I think, this approach with asking the legalization about the final vector size
is the most straight-forward.

I've checked, and i believe this is endianness-agnostic as per alive2.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106399

Files:
  llvm/include/llvm/Analysis/TargetTransformInfo.h
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/lib/Analysis/TargetTransformInfo.cpp
  llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  llvm/test/Transforms/VectorCombine/X86/load-inseltpoison.ll
  llvm/test/Transforms/VectorCombine/X86/load-widening.ll
  llvm/test/Transforms/VectorCombine/X86/load.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106399.360276.patch
Type: text/x-patch
Size: 16602 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210720/7944bb4f/attachment.bin>


More information about the llvm-commits mailing list