You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ; :0 [#uses=1]
zext i1 %0 to i32 ; :0 [#uses=1]
That should be :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.
Extended Description
The following program assembles with llvm-as:
define i32 @test1(i32 %a, i32 %b) {
entry:
icmp eq i32 %b, %a ; :0 [#uses=1]
zext i1 %0 to 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 ; :0 [#uses=1]
zext i1 %1 to i32 ; :1 [#uses=1]
ret i32 %1
}
The text was updated successfully, but these errors were encountered: