See here: https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/X86/X86InterleavedAccess.cpp#L219 Value *NewBasePtr = Builder.CreateGEP(VecBaseTy, VecBasePtr, Builder.getInt32(i)); Instruction *NewLoad = Builder.CreateAlignedLoad(VecBaseTy, NewBasePtr, LI->getAlign()); Newly created loads inherit the original load's alignment. This is not correct, as the original load may have a larger alignment than the GEP done above. A concrete failure we see is in: Transforms/InterleavedAccess/X86/interleavedLoad.ll define <32 x i8> @interleaved_load_vf32_i8_stride3(* %ptr) { %wide.vec = load <96 x i8>, * %ptr, align 128 ... } => define <32 x i8> @interleaved_load_vf32_i8_stride3(* %ptr) { %1 = bitcast * %ptr to * %2 = gep * %1, 16 x i32 0 %3 = load <16 x i8>, * %2, align 128 ; <-- this is not 128-byte aligned %4 = gep * %1, 16 x i32 1 %5 = load <16 x i8>, * %4, align 128 %6 = gep * %1, 16 x i32 2 %7 = load <16 x i8>, * %6, align 128 ... } Report: https://web.ist.utl.pt/nuno.lopes/alive2/index.php?hash=72296a443c683892&test=Transforms%2FInterleavedAccess%2FX86%2FinterleavedLoad.ll
Why isn't %3 128 byte aligned? That GEP has an index of 0 so doesn't move the pointer. I get that the other loads %5 and %7 are wrong.
(In reply to Craig Topper from comment #1) > Why isn't %3 128 byte aligned? That GEP has an index of 0 so doesn't move > the pointer. I get that the other loads %5 and %7 are wrong. Yes, my mistake. %3 is aligned, just not the subsequent loads.
Fixed in https://reviews.llvm.org/D80276