[llvm-bugs] [Bug 51377] New: Not vectorizing due to memcpy between stack arrays of trivially copyable struct

[via llvm-bugs]

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

            Bug ID: 51377
           Summary: Not vectorizing due to memcpy between stack arrays of
                    trivially copyable struct
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: joachim at joameyer.de
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Hi all,

I work on an LLVM plugin performing loop fission. To keep state between loops,
I have to convert existing `alloca`s to arrays and also generate `alloca`
arrays for dependencies on SSA values.
I also mark the loops as being parallel and set vectorize.enable. This then
regularly generates a warning that at least the first loop can't be vectorized.
With -Rpass-analysis, -debug-only,.. I figured out that this mostly comes from
a trivially copyable type being passed to an inlined function (the source is
not used otherwise), which generates a llvm.memcpy... between two allocas. Due
to my transformations, these allocas become an array of type [1024 x
%"struct.."].
As soon as both allocas become arrays, this loop cannot be vectorized.

I took the IR and llvm-reduced it, the upper editor contains the code with both
allocas being arrays and the lower editor shows the IR with just the copied-to
alloca being an array, the latter case vectorizes fine:
https://godbolt.org/z/r68hnehz9

Running both examples with `-sroa` instead of `-O3` reveals that in the two
array case SROA doesn't do anything to the allocas but for the second case,
SROA kicks in.

Obviously, for this simple case, I can avoid this by analyzing the source
alloca's usage before turning it into an array, but I'm wondering whether this
case might come up in standard C++ code as well and thus should be handled.
(and with a preliminary optimization from my side in-place it still seems there
are some memcpys left, which lead to not vectorizing the whole loop, which is
pretty bad)

Hope the problem description is exhaustive enough, if not please ask for
clarifications. I'm happy to contribute to the resolution of this problem, if
given hints :)

-- 
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/20210806/b2ac532c/attachment.html>