[LLVMbugs] [Bug 1753] New: Alias analysis/other optimizations don' t work in the presence of ptrtoint/inttoptr

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=1753

           Summary: Alias analysis/other optimizations don't work in the
                    presence of ptrtoint/inttoptr
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Two llvm functions:

define i32 @myfunc(i32 %a) {
EntryBlock:
  %mem = alloca [16384 x i32]
  %memptr = getelementptr [16384 x i32] * %mem, i32 0, i32 0
  %memint = ptrtoint i32 * %memptr to i32
  %memint2 = add i32 %memint, 4
  %memptr2 = inttoptr i32 %memint2 to i32*
  store i32 20, i32* %memptr2
  store i32 10, i32* %memptr
  %retint = load i32* %memptr2
  ret i32 %retint
}

define i32 @myfunc2(i32) {
EntryBlock:
  %mem = alloca [16384 x i32]
  %memptr = getelementptr [16384 x i32] * %mem, i32 0, i32 0
  %memptr2 = getelementptr [16384 x i32] * %mem, i32 0, i32 1
  store i32 20, i32* %memptr2
  store i32 10, i32* %memptr
  %retint = load i32* %memptr2
  ret i32 %retint
}

Note that in both of these functions, %memptr2 ends up with the same value.

Results after running code through "opt -std-compile-opts" then "llc"

_myfunc:
        movl    $65536, %eax
        call    __alloca
        movl    $20, 4(%esp)
        movl    $10, (%esp)
        movl    4(%esp), %eax
        addl    $65536, %esp
        ret

_myfunc2:
        movl    $20, %eax
        ret

If I don't run the code through opt, both functions end up exactly the same.

I'd appreciate any tips on how to fix this; I'm generating code like myfunc.  I
can probably work around it in my generating code (essentially by avoiding the
conversion in easy casea), but it would make things more complicated, so it
would be nice if llvm could handle it.

(My best guess to the issue is that target-independent optimizations assume
that a pointer from inttoptr can alias anything, and by the time the
machine-specific information is available, the passes that deal with these
sorts of optimizations have already run.)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.