[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