I think you may need to update your CFE and rebuild. I compiled the test
using my local build and I didn't get the results you see below. I'm
also very surprised to see this output. The first %tmp.11 should have
been %tmp.1 .. not sure how it got corrupted. In any event, the
attachment is obviously generated by code that runs quite differently
because the virtual register names used are quite different from what
you have below. If you updated last week sometime, is it possible you
got caught between some of Chris' "determinism" changes?
Anyway, try an update and let us know how it goes.
I think you may need to update your CFE and rebuild. I compiled the test
using my local build and I didn't get the results you see below. I'm
also very surprised to see this output. The first %tmp.11 should have
been %tmp.1 .. not sure how it got corrupted. In any event, the
attachment is obviously generated by code that runs quite differently
because the virtual register names used are quite different from what
you have below. If you updated last week sometime, is it possible you
got caught between some of Chris' "determinism" changes?
Anyway, try an update and let us know how it goes.
This still happens after update and rebuild:
$ /home/ghost/build/llvm-gcc/install/bin/gcc -g -S -fno-inline -o test.llvm
tests/2003-05-26-Shorts.c
$ gccas -disable-inlining test.llvm -o test.bc
$ llvm-dis -f test.bc
$ less test.ll
........
int %main(int %argc, sbyte** %argv) {
entry:
call void %__main( )
%tmp.11 = call ulong %getL( ) ; <ulong> [#uses=16]
%tmp.3 = cast ulong %tmp.11 to long ; <long> [#uses=
6]
%tmp.5 = cast ulong %tmp.11 to uint ; <uint> [#uses=
6]
%tmp.7 = cast ulong %tmp.11 to int ; <int> [#uses=7
]
%tmp.9 = cast ulong %tmp.11 to ushort ; <ushort> [#use
s=3]
%tmp.11 = cast ulong %tmp.11 to short
Okay, I've replicated your results, but I don't think there's an error here, its just not nice output from the disassembler. The first %tmp.ll is of type long. The second one is of type short. I think that's valid for LLVM. That is, the SSA form depends on both the type and name of the virtual register. In any event, llvm-as seems to compile the llvm-dis output just fine.
Okay, I've replicated your results, but I don't think there's an error here,
its just not nice output from the disassembler. The first %tmp.ll is of type
long. The second one is of type short. I think that's valid for LLVM. That
is, the SSA form depends on both the type and name of the virtual register.
In any event, llvm-as seems to compile the llvm-dis output just fine.
Just for confirmation, Reid is right here. Conceptually, LLVM has a
separate symbol table for values of each type.