On Sat, 14 Sep 2002, Casey Carter wrote:> Does our pass need to ensure that the new names it creates for the field
> allocations are, in fact, unique?
No. Names in LLVM are completely meaningless to the compiler (with the
exception of names on externally visible globals which are used for
linking). Names are basically used to make debugging your pass and
inspecting the output easier. Because there is "no meaning" in the
names,
the LLVM infrastructure will automatically rename a symbol table conflict
to something unique when it gets added to the program.
So, it's possible you could just name every value you insert "x"
and have
the compiler insert x1, x2, x3, x4... but it's not a good idea. Doing so
would make the output code harder to understand. My suggestion would be
transform something like this:
X = alloca { { {int} }, float }
Y = getelementptr { { {int} }, float }* X, uint 0, ubyte 0, ubyte 0, ubyte 0
Z = getelementptr { { {int} }, float }* X, uint 0, ubyte 1
into:
X.f0 = alloca {{int}}
X.f1 = alloca float
Y = getelementptr {{int}}* %X.f0, uint 0, ubyte 0, ubyte 0
(all uses of Z now use X.f1)
... after a single promotion of the structure. After another iteration of
the worklist:
X.f0.f0 = alloca {int}
X.f1 = alloca float
Y = getelementptr {int}* %X.f0.f0, uint 0, ubyte 0
etc...
To do this, you might find the include/Support/StringExtras.h file useful,
it contains an efficient function to turn an integer into a string.
-Chris
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/