Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

X86InterleavedAccess introduces misaligned loads #45302

Closed
nunoplopes opened this issue May 17, 2020 · 3 comments
Closed

X86InterleavedAccess introduces misaligned loads #45302

nunoplopes opened this issue May 17, 2020 · 3 comments
Labels
backend:X86 bugzilla Issues migrated from bugzilla miscompilation

Comments

@nunoplopes
Copy link
Member

Bugzilla Link 45957
Resolution FIXED
Resolved on May 27, 2020 05:30
Version trunk
OS All
CC @topperc,@gchatelet,@aqjune,@RKSimon,@regehr,@rotateright
Fixed by commit(s) 5b84ee4

Extended Description

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

@topperc
Copy link
Collaborator

topperc commented May 17, 2020

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.

@nunoplopes
Copy link
Member Author

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.

@gchatelet
Copy link
Contributor

Fixed in https://reviews.llvm.org/D80276

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend:X86 bugzilla Issues migrated from bugzilla miscompilation
Projects
None yet
Development

No branches or pull requests

3 participants