[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