================
@@ -5086,6 +5089,67 @@ bool SROA::presplitLoadsAndStores(AllocaInst &AI,
AllocaSlices &AS) {
return true;
}
+/// Try to canonicalize a homogeneous struct partition to a vector type.
+///
+/// We can do this if all the elements of the struct are the same and tightly
+/// packed. This can sometimes eliminate allocas because structs cannot get
+/// promoted to LLVM values, but vectors can.
+///
+/// We only apply this transformation when all users of the alloca are memory
+/// intrinsics. Otherwise, if there is a load or store of some other type to
the
+/// partition, SROA would select that type.
+///
+/// Applying this transformation too early may hinder memcpyopt, which may
+/// generate better code when eliminating allocas. For example, see
----------------
yxsamliu wrote:
@arsenm Adding to Yonah's reply: the general SROA <-> memcpyopt relationship is
already a back-and-forth — each pass works best on its own preferred IR shape,
and the pipeline runs them multiple times to let them clean up after each
other. What this PR adds is a new SROA trick (promote memcpy-only struct
allocas to a vector SSA value) that, when run too early, breaks the memcpy
chain that memcpyopt was about to simplify. Pushing the trick to run after
memcpyopt preserves the existing handoff: memcpyopt does its memcpy-level
reasoning first, then late SROA picks up whatever memcpyopt couldn't eliminate.
Teaching memcpyopt to reconstruct memcpys from arbitrary load/store pairs would
help, but it's a much larger change with its own correctness surface, and not
specific to this PR.
https://github.com/llvm/llvm-project/pull/165159
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
