LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 45957 - X86InterleavedAccess introduces misaligned loads
Summary: X86InterleavedAccess introduces misaligned loads
Status: RESOLVED FIXED
Alias: None
Product: libraries
Classification: Unclassified
Component: Backend: X86 (show other bugs)
Version: trunk
Hardware: All All
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords: miscompilation
Depends on:
Blocks:
 
Reported: 2020-05-17 08:00 PDT by Nuno Lopes
Modified: 2020-05-27 05:30 PDT (History)
7 users (show)

See Also:
Fixed By Commit(s): 5b84ee4f61419


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nuno Lopes 2020-05-17 08:00:31 PDT
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
Comment 1 Craig Topper 2020-05-17 10:28:43 PDT
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.
Comment 2 Nuno Lopes 2020-05-17 11:47:20 PDT
(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.
Comment 3 Guillaume Chatelet 2020-05-27 05:19:47 PDT
Fixed in https://reviews.llvm.org/D80276