[LLVMbugs] [Bug 309] NEW: [vmcore] Code quality problem due to long operand of getelementptr

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Thu Apr 1 09:18:18 PST 2004


http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=309

           Summary: [vmcore] Code quality problem due to long operand of
                    getelementptr
           Product: libraries
           Version: 1.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org


Whenever someone has time to work on Bug 82, we should also fix getelementptr to
take arbitrary integer operands for the array indices as well.  Requiring long
indexes for array and pointer subscripting causes performance problems in some
code.  For example, on 164.gzip, we see the following situation:

In the X86 world, we efficiently handle code like this:
%X = cast int to long
%y = gep ... long %X

... by not actually promoting X to 64 bits (we fold the cast into the
getelementptr).

However, in 164.gzip, the code input to the optimizer looks like this:

%X = cast int %x to long
%B = getelementptr int* %A, long %X
%Y = cast int %y to long
%C = getelementptr int* %B, long %Y

which the optimizer turns into:

%X = cast int %x to long
%Y = cast int %y to long
%tmp = add long %X, %Y
%C = getelementptr int* %A, long %tmp

The X86 instruction selector performs the 64-bit add, then takes the low 32-bits
of it for the pointer arithmetic.  64-bit adds are much slower than 32-bit ones,
which causes a performance problem.

This is just a placeholder bug so that this issue doesn't get forgotten.

-Chris



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.



More information about the llvm-bugs mailing list