Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

LLVM Lint analysis pass incorrectly reporting misaligned reference #36911

Open Quuxplusone opened 6 years ago

Quuxplusone commented 6 years ago
Bugzilla Link PR37940
Status NEW
Importance P enhancement
Reported by Raoul Gough (raoul.gough@baml.com)
Reported on 2018-06-26 06:02:10 -0700
Last modified on 2018-06-26 06:03:39 -0700
Version 6.0
Hardware PC Linux
CC llvm-bugs@lists.llvm.org, raoul.gough@baml.com
Fixed by commit(s)
Attachments alignment.ll (836 bytes, text/plain)
Blocks
Blocked by
See also
Created attachment 20468
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
...
Quuxplusone commented 6 years ago

Attached alignment.ll (836 bytes, text/plain): Human-readable bitcode for reproducing the Lint warning