Current, llvm-upgrade is not handling redefinition of named values properly. This invariably is the result of the collapsed type planes. For example, code that previously defined a value in both the UInt and Int type planes will now not work because those type planes have merged to just i32. The two values will appear as redefinitions in the i32 type plane for the same symbol. One quick thing to help with this is to drop useless bitcasts, like: %tmp = bitcast i32 %tmp to i32 These result from old signedness conversions where the bitcast used to be: %tmp = bitcast uint %tmp to int Such bitcasts can now just be dropped by llvm-upgrade. However, this isn't sufficient, its still quite possible that code like this: %tmp = load uint* %uptr %tmp = load int* %sptr won't work because it now looks like: %tmp = load i32* %uptr %tmp = load i32* %sptr and a redefinition error occurs. The solution involves tracking the symbol table in llvm-upgrade and making sure that no re-definitions occur. If they do, a simple name uniqueness algorithm should be sufficient.
Mine.
This patch: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061225/041897.html eliminates useless bitcasts. More to come.
This patch provides a partial implementation of variable name modification resulting from type plane collapsing. This handles the most frequently occurring cases and is sufficient to get llvm/test working. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/041905.html The patch makes the upgrade parser to keep track of types more faithfully and use this information to resolve name conflicts resulting from collapsed type planes. The type planes have collapsed because the integer types are now signless. For example, uint and int have became i32. Where two planes existed previously for uint and int, only i32 now exists. Any variable names depending on the type planes to make the identifier unique would cause a conflict after upgrade. This patch resolves that conflict for many but not all cases. Situations involving the integer types and pointers to them are handled by this patch. However, there are corner cases that are not handled well, such as: %t1 = type { uint, int } %t2 = type { int, uint } void %myfunc(%t1* one, %t2* two) { %var = load %t1* one %var = load %t2* two } In the scenario above, %t1 and %t2 are really the same type: { i32, i32 } Consequently attempting to name %var twice will yield a redefinition error when assembled. More work needs to be done to complete the handling of these cases.
This is a duplicate and now fixed. *** This bug has been marked as a duplicate of 1076 ***