[PATCH] D80276: [Alignment] Fix misaligned interleaved loads

[Craig Topper via Phabricator via llvm-commits]

craig.topper added inline comments.


================
Comment at: llvm/test/Transforms/InterleavedAccess/X86/interleaved-accesses-64bits-avx.ll:45
 ; CHECK-NEXT:    [[TMP2:%.*]] = getelementptr <4 x i64>, <4 x i64>* [[TMP1]], i32 0
-; CHECK-NEXT:    [[TMP3:%.*]] = load <4 x i64>, <4 x i64>* [[TMP2]], align 16
+; CHECK-NEXT:    [[TMP3:%.*]] = load <4 x i64>, <4 x i64>* [[TMP2]], align 32
 ; CHECK-NEXT:    [[TMP4:%.*]] = getelementptr <4 x i64>, <4 x i64>* [[TMP1]], i32 1
----------------
jdoerfert wrote:
> lebedev.ri wrote:
> > nlopes wrote:
> > > jdoerfert wrote:
> > > > nlopes wrote:
> > > > > craig.topper wrote:
> > > > > > The original load was only align 16 how did we get to 32?
> > > > > this is probably the ABI alignment for the vector is 32 bytes(?) and the code now will just take that.
> > > > But it shouldn't. (Now it's gone so OK)
> > > I don't think there's any problem in increasing alignment. All data needs to be aligned at least by the ABI requirement. Alignment given in memory instructions is only meaningful if greater than the minimum that the ABI specifies.
> > So you are saying that every underaligned (incl. align=1) load is undefined?
> > That is not my reading of langref..
> I'm usually not leaving the IR and that is how I understood IR semantics. @arsenm @efriedma 
> thoughts?
The vector load would have been created from scalar loads by the loop vectorizer. The only alignment the loop vectorizer saw was the scalar load. And whatever better alignment might have been inferred. There's no guarantee that a vector load created by the vectorizer would be aligned to anything more than the scalar.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D80276/new/

https://reviews.llvm.org/D80276