[llvm-bugs] [Bug 33878] New: BasicAA incorrectly assumes different address spaces don't alias

[via llvm-bugs]

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

            Bug ID: 33878
           Summary: BasicAA incorrectly assumes different address spaces
                    don't alias
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Keywords: miscompilation
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: nunoplopes at sapo.pt
                CC: davide at freebsd.org, dberlin at dberlin.org,
                    gil.hur at sf.snu.ac.kr, hfinkel at anl.gov,
                    jeehoon.kang at sf.snu.ac.kr, juneyoung.lee at sf.snu.ac.kr,
                    llvm-bugs at lists.llvm.org, regehr at cs.utah.edu,
                    sanjoy at playingwithpointers.com

BasicAA assumes that pointers of different address spaces can't alias.  This is
not true is general, though.

in function BasicAAResult::aliasCheck():

  if (O1 != O2) {
    // Most objects can't alias null.
    if ((isa<ConstantPointerNull>(O2) && isKnownNonNull(O1)) ||
        (isa<ConstantPointerNull>(O1) && isKnownNonNull(O2)))
      return NoAlias;


There are two bugs here:
 - if O1 is null, and O2 is non-null, but they are in different address spaces,
then nothing can be concluded (unless we add target-specific hooks to tell us
that information).

 - isKnownNonNull assumes alloca produces a non-null result, which is not true
in general for address space != 0:

  bool llvm::isKnownNonNull(const Value *V) {
    assert(V->getType()->isPointerTy() && "V must be pointer type");

    // Alloca never returns null, malloc might.
    if (isa<AllocaInst>(V)) return true;
    (...)
  }

-- 
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/20170721/07c15bf2/attachment.html>