suboptimal code generation in pointer comparison (this also affects std::vector.push_back())

[llvmbot]

Bugzilla Link	11238
Resolution	FIXED
Resolved on	Feb 25, 2012 13:19
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@nlewycky

Extended Description

Test Case:

; ModuleID = 'x.ll'
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"

%t = type { i32, i32 }

define i32 @​main() nounwind readnone {
r1:
%x = alloca %t, align 8
%a = getelementptr %t* %x, i64 0, i32 0
%b = getelementptr %t* %x, i64 0, i32 1
%equal = icmp eq i32* %a, %b
%merge = select i1 %equal, i32 1, i32 2
ret i32 %merge
}

I think the issue should be obviously.
Have fun fixing it. This code occurs also on code generation of the C++ template std::vector:

#include
#include

using namespace std;

int main() {
vector v;
v.push_back(1);
v.push_back(2);
v.push_back(3);
for(vector::iterator it = v.begin(); it < v.end(); it++) {
cout << *it << endl;
}
}

[llvmbot]

Note that the code generators eliminate this. Your example codegens to

main: # @​main

BB#0: # %r1

movl	$2, %eax
ret

[llvmbot]

Note that the code generators eliminate this. Your example codegens to

main: # @​main

BB#0: # %r1

movl    $2, %eax
ret

Optimizations in the code generator are very late. They can't pull in other optimizations (which i hope with a fix of this, because I'm interested in how std::vector really looks on llvm)

[llvmbot]

Well, you did title this "suboptimal code generation" :)
I agree that this should be fixed at the IR level, presumably in instsimplify.

[llvmbot]

Goal after one (and not three) runs of opt -O3
this is the result after

opt -S -O3 x.ll | opt -O3 | opt -O3 -S

[llvmbot]

I played a bit with opt passes and found out, that

opt x.ll -basicaa -aa-eval -gvn -jump-threading -instsimplify

[nlewycky]

Fixed in r151449!