Hmm... attachment is > 1MB, so bugzilla complains that it's too large, sending
it to Reid.

Mine.

For the UnexpectedUndef.ll file, here's my analysis:

This file isn't in 1.9 LLVM assembly format. It uses i32 which is a 2.0 feature.
It also uses 2.0 identifier syntax (@name and @"name"). I have changed
llvm-upgrade to recognize (i1, i8, i16, i32 and i64) but there isn't much I can
do about @"name" .. its just not lexically compatable with 1.9 assembly.

For the FunctionRedefinition.ll file, we get three symptoms:

1. Rename warning:

warning: Renaming function 'cdrom_read_subchannel' as
'cdrom_read_subchannel.upgrd.806' may cause linkage errors

These can be safely ignored. llvm-upgrade is just telling you that it is
renaming something and if you link this module with something else that renaming
might cause problems. The upgraded program will either be okay as is or you will
need to manually rename these items back (after resolving naming conflicts).
This occurs when you have overloaded functions (same name, different type).

2. Redefinition that should not cause an error:

error: Redefinition of function 'msf_to_lba'

This occurs when two external functions of the same name and type are
encountered. This was illegal in 1.9 and is illegal now. However, the two
functions in question here are both "internal" linkage. I will make llvm-upgrade
quietly rename one of these functions. This can't produce any linkage errors
because of the internal linkage type.

3. Infinite loop after parsing in ResolveDefinitions.

This one has something to do with the csretcc upgrade to sret param attr. For
some reason its not finding the type and looping infinitely while trying to get
the type description. The solution is to fix the problem so it can correctly
cast the function type.

The smbd.ll file has problem #​1 and #​3 from the last post.

I have fixed the @"name" problem from UnexpectedUndef.ll, but now there's
another problem. For some reason it is not parsing i32 -1 correctly. I'm not
sure why.

I'll investigate these remaining items. In the mean time, here's a partial fix
that solves some of the issues:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044130.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044131.html

For UnexpectedUndef.ll, you will need to do some manual upgrades for things that
are not supported in 1.9, to wit:
a) %name = global i32 -1
--> i32 is accepted as uint and -1 is not valid for uint
b) define keywoard: just remove these from the file and it should be fine
c) put "implementation" keyword before the first function definition
This file is just too divergent from 1.9 assembly for it to handle properly. The
changes I've made should significantly reduce your editing burden.

llvm-upgrade now parses and upgrades smbd.ll (with some really nasty sret chagnes).

named-checkconf.ll now parses and upgrades correctly.

FunctionRedefinition.ll now parses and upgrades correctly.

The basic block renaming has now been handled too.

Test Cases:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044121.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044122.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044164.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044165.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044177.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044178.html

Resolved with these patches:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044130.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044131.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044166.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044173.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044174.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044175.html