[llvm-bugs] [Bug 37940] New: LLVM Lint analysis pass incorrectly reporting misaligned reference

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37940

            Bug ID: 37940
           Summary: LLVM Lint analysis pass incorrectly reporting
                    misaligned reference
           Product: new-bugs
           Version: 6.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: raoul.gough at baml.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 20468
  --> https://bugs.llvm.org/attachment.cgi?id=20468&action=edit
Human-readable bitcode for reproducing the Lint warning

The attached example bitcode generates a lint warning using opt -O3 -lint:

$ llvm-as -o - alignment.ll | opt -O3 -lint -o /dev/null
Undefined behavior: Memory reference address is misaligned
  store i64 4611686018427387904, i64* bitcast ([3 x double]* @temp_3__storage__
to i64*), align 16

The cause is that the optimizer relies on DataLayout::getPreferredAlignment
which gives 16 byte alignment for temp_3__storage__ because it's a static of
sufficient size (see code snippet below). Then Lint::visitMemoryReference uses
getABITypeAlignment which gives an alignment of only 8 for temp_3__storage__.

unsigned DataLayout::getPreferredAlignment(const GlobalVariable *GV) const {
...
  if (GV->hasInitializer() && GVAlignment == 0) {
    if (Alignment < 16) {
      // If the global is not external, see if it is large.  If so, give it a
      // larger alignment.
      if (getTypeSizeInBits(ElemType) > 128)
        Alignment = 16;    // 16-byte alignment.
    }
  }

I think the code generator actually does emit temp_3__storage__ with 16-byte
alignment, but either way Lint and the optimizer should be using the same value
to avoid the warning.

Example call stack during optimization showing the relevant call to
getPreferredAlignment. This is from llvm-5.0.0 but the warning is the same in
llvm-6.0.0 as well.

#0  llvm::DataLayout::getPreferredAlignment (this=0x3f91728, GV=0x2f011d8) at
llvm-5.0.0.src/lib/IR/DataLayout.cpp:773
#1  0x00007ffff4f31f8e in llvm::Value::getPointerAlignment (this=0x2f011d8,
DL=...) at llvm-5.0.0.src/lib/IR/Value.cpp:656
#2  0x00007ffff4ab324b in computeKnownBits (V=0x2f011d8, Known=..., Depth=1,
Q=...) at llvm-5.0.0.src/lib/Analysis/ValueTracking.cpp:1585
#3  0x00007ffff4ab0e6b in computeKnownBitsFromOperator (I=0x2eff348, Known=...,
Depth=0, Q=...) at llvm-5.0.0.src/lib/Analysis/ValueTracking.cpp:1066
#4  0x00007ffff4ab3214 in computeKnownBits (V=0x2eff348, Known=..., Depth=0,
Q=...) at llvm-5.0.0.src/lib/Analysis/ValueTracking.cpp:1581
#5  0x00007ffff4ab2be6 in computeKnownBits (V=0x2eff348, Depth=0, Q=...) at
llvm-5.0.0.src/lib/Analysis/ValueTracking.cpp:1478
#6  0x00007ffff4aab541 in llvm::computeKnownBits (V=0x2eff348, DL=..., Depth=0,
AC=0x2ec77d0, CxtI=0x2f01720, DT=0x3f988f0, ORE=0x0) at
llvm-5.0.0.src/lib/Analysis/ValueTracking.cpp:155
#7  0x00007ffff51b2b5f in llvm::getOrEnforceKnownAlignment (V=0x2eff348,
PrefAlign=0, DL=..., CxtI=0x2f01720, AC=0x2ec77d0, DT=0x3f988f0) at
llvm-5.0.0.src/lib/Transforms/Utils/Local.cpp:1042
#8  0x00007ffff5c97f93 in llvm::getKnownAlignment (V=0x2eff348, DL=...,
CxtI=0x2f01720, AC=0x2ec77d0, DT=0x3f988f0) at
llvm-5.0.0.src/include/llvm/Transforms/Utils/Local.h:192
#9  0x00007ffff5c986c7 in llvm::InstCombiner::SimplifyMemTransfer
(this=0x7fffffffac60, MI=0x2f01720) at
llvm-5.0.0.src/lib/Transforms/InstCombine/InstCombineCalls.cpp:175
#10 0x00007ffff5c9f421 in llvm::InstCombiner::visitCallInst
(this=0x7fffffffac60, CI=...) at
llvm-5.0.0.src/lib/Transforms/InstCombine/InstCombineCalls.cpp:1925
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180626/0a2aa8ba/attachment.html>