llvm-upgrade can cause redefinition errors

[llvmbot]

Bugzilla Link	1070
Resolution	DUPLICATE
Resolved on	Mar 06, 2010 14:00
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

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.

[llvmbot]

Mine.

[llvmbot]

This patch:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20061225/041897.html

eliminates useless bitcasts.

More to come.

[llvmbot]

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.

[llvmbot]

This is a duplicate and now fixed.

*** This bug has been marked as a duplicate of 1076 ***

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#1076