[PATCH] D108325: [SLP] Allow overlapping vector accesses (WIP).

Florian Hahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 18 12:45:31 PDT 2021


fhahn created this revision.
fhahn added reviewers: spatel, dtemirbulatov, anton-afanasyev, ABataev.
Herald added subscribers: hiraditya, kristof.beyls.
fhahn requested review of this revision.
Herald added a project: LLVM.

NOTE: This is an extremely rough draft intended to start a wider
discussion on how to allow overlapping memory accesses.

I would like to extend the SLP vectorizer to support overlapping vector
loads. This allows vectorizing cases where we operate on overlapping
vectors that can be loaded efficiently

The simplest C example is something like the snippet below, where we add
<s[0], s[1], s[2], s[3]> and <s[1], s[2], s[3], s[4]>. Those vectors can
be directly loaded from &s[0] and &s[1]. The problem is that currently
overlapping bundles are not allowed, which leads to gathering the second
vector, which is not profitable on AArch64.

  void test(int *s,int* __restrict__ d) {
      for (int x=0;x<4;x++,s++) {
          d[x] = s[0] + s[1];
      }
  }

The invariant that bundles should not overlap seems to be relied on and
encoded in multiple places. In this patch, I mostly tried to disable
various checks and assertions. It effectively allows overlapping
bundles, iff they first entry in Scalars is unique.

This clearly is not a proper solution, but I am hoping that sharing the
patch can be the start of a discussion on how to properly address the
limitations. It would be great if you could share your thoughts.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D108325

Files:
  llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
  llvm/test/Transforms/SLPVectorizer/AArch64/overlapping-vector-loads.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D108325.367306.patch
Type: text/x-patch
Size: 9531 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210818/ade51abb/attachment.bin>


More information about the llvm-commits mailing list