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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

Please regenerate the IR tests and commit that separately.



================
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
----------------
craig.topper wrote:
> 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.
The known alignment of a memory operation is precisely the specified alignment, no more or less.  This has always been true.  There are some cases where a "zero" alignment has a special meaning, but I've been working on eradicating that.

And yes, realistically, there isn't any reason to expect that vector loads created by the vectorizer are naturally aligned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80276