Merge commit 72a20b8e2987 from llvm git (by Gabriel Baraldi): [SLPVectorizer] Check std::optional coming out of getPointersDiff

[pkubaj]

Summary

clang 21.1.8 dies with clang frontend command failed with exit code 133 (SIGTRAP) in the SLP vectorizer when building audio/csound 6.15.0 on powerpc64le, both in the 15.2-BETA1 poudriere jail and natively on a 15.2 host (3/3). The trap is libc++'s hardening check on *Diff in BoUpSLP::canVectorizeLoads(): getPointersDiff(Ptr0, PtrN) returned nullopt. That pair is not guaranteed to be computable, sortPtrAccesses() only validated the distances relative to PointerOps[0], and here SCEV cannot fold the loop-variant inttoptr base, so the two extremes end up with differently shaped AddRec starts.

Upstream fixed this in https://github.com/llvm/llvm-project/pull/175784 (issue https://github.com/llvm/llvm-project/issues/175768), commit 72a20b8e2987, cherry-picked to release/22.x as b30dd8f1ad83 but never to 21.x. The canVectorizeLoads() hunk is verbatim. Upstream's second hunk touches analyzeConstantStrideCandidate(), which in llvm 21 is still the static isStridedLoad() helper with the same unchecked dereference, so it is converted the same way (distances via PointerOps[0]). The upstream regression test is not included since we don't carry llvm/test.

The bug is target independent (the reduced IR also crashes with -mtriple x86_64 and aarch64), it is just the hardened libc++ that makes it visible on FreeBSD. Could this also go into releng/15.2 while it is still in BETA? csound is the only port hit in the current powerpc64le 15.2 bulk so far.

Test Plan

The reduced reproducer (llvm-reduce output of the crashing function, 33 lines) traps with the llvm20 and llvm21 ports' opt -passes=slp-vectorizer and passes with llvm22, which already has the upstream change. With the patch, SLPVectorizer.cpp compiles cleanly with the lib/clang build rules on 15.2 powerpc64le. A full clang build to recompile the csound TU is running, I'll follow up with the result.

[dim]

I don't see any issue with merging an upstream fix, but it's up to @cperciva (and any other releng people) to determine whether it can still go into 15.2. Since it is an upstream fix, it should be fairly safe.