The following program assembles with llvm-as: define i32 @test1(i32 %a, i32 %b) { entry: icmp eq i32 %b, %a ; <i1>:0 [#uses=1] zext i1 %0 to i32 ; <i32>:0 [#uses=1] ret i32 %0 } The type of %0 is simultaneously i1 and i32. By contrast, naming the variable %A makes it invalid. This does not assemble define i32 @test2(i32 %a, i32 %b) { entry: %A = icmp eq i32 %b, %a %A = zext i1 %A to i32 ret i32 %A } with the error "Redefinition of value 'A' of type 'i32'" which is desired. I'd like this C code: int test1(int a, int b) { return a == b; } to produce this llvm assembly: define i32 @test1(i32 %a, i32 %b) { entry: icmp eq i32 %b, %a ; <i1>:0 [#uses=1] zext i1 %1 to i32 ; <i32>:1 [#uses=1] ret i32 %1 }
You're right, this is certainly a bug. This may have llvm-upgrade implications, what do you think Reid? -Chris
I really don't get it. If there's a bug here, it is only in the output of the comment: icmp eq i32 %b, %a ; <i1>:0 [#uses=1] zext i1 %0 to i32 ; <i32>:0 [#uses=1] That should be <i32>:1 on the zext instruction. Otherwise it is fine. The program should assemble because %0 (icmp) is type i1 and %1 (zext) is type i32. Giving the same name to these instructions should fail because of redefinition of a name. I don't see where %0 is redefined. This has no bearing on llvm-upgrade as far as I can see.
No, look at the ret: ret i32 %0 That's returning the result of the zext, not the icmp.
Okay, sorry, missed that. Yeah, its a bug.
Fixed with these patches: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070319/045938.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070319/045939.html http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070319/045940.html Test case here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070319/045942.html