[llvm] [LoadStoreVectorizer] Batch alias analysis results to improve compile time (PR #147555)

Nikita Popov via llvm-commits llvm-commits at lists.llvm.org
Wed Jul 9 08:51:25 PDT 2025


================
@@ -543,6 +544,10 @@ std::vector<Chain> Vectorizer::splitChainByMayAliasInstrs(Chain &C) {
   for (const auto &E : C)
     ChainOffsets.insert({&*E.Inst, E.OffsetFromLeader});
 
+  // Across a single invocation of this function the IR is not changing, so
+  // using a batched Alias Analysis is safe and can reduce compile time.
+  BatchAAResults BatchAA(AA);
----------------
nikic wrote:

> That's a fair point. I suggest we revisit that idea in a future change, as I have some follow up changes to the LSV and I think it would be best to consider the correctness of expanding the lifetime of this cache only once we have that complete picture.

I agree that it's best to do this in a future change. This one is trivially correct, the extension is less obvious.

> Unless you can give me more specifics about what exactly counts as invalidating the cache and what would not. The comment above the BatchAAResult class specifies "it is intended to be used only when there are no IR changes inbetween queries." I can see how that restriction could be relaxed under certain conditions, but I don't have a complete understanding of those conditions.
>
> For instance, I have an optimization I am going to propose that fills holes in non-contiguous chains with newly created geps and loads/stores. Would the creation of those instructions invalidate the cache somehow?

The requirement for BatchAA is basically "create xor erase". It's okay to create new instructions, and it's okay to erase instructions, but it's not okay to do both, due to address reuse.

https://github.com/llvm/llvm-project/pull/147555


More information about the llvm-commits mailing list