I just updated the linux "llvm-gcc" to work with a new, correct, model
for
global variable initialization. This does not change the LLVM api in any
way, but it does change the "meaning" of some programs.
Before, if you compiled the following C code:
int global1;
extern int global2;
int global3 = 0;
You would get LLVM code that looked like this:
%global1 = uninitialized global int
%global2 = uninitialized global int
%global3 = global int 0
This is obviously bad, because there was no way to know whether or not a
variable was uninitialized or external, and there was no difference
between the two cases.
The new model is that a global variable must always have an initializer if
is not external. Before, the implicit initializer was zero: now this is
explicit. The above code now compiles to:
%global1 = global int 0
%global2 = uninitialized global int
%global3 = global int 0
Which conveys the right information to the LLVM infrastructure.
The only bad part of this change is that the "initialized" flag is
really
a "not external" flag. Eventually I will rename it, so that global
variables are external or not, and the uninitialized flag will go away.
Until then, we just have a poorly named flag.
Currently the Sparc backend tries to make use of the .bss section of the
executable (which is automatically zeroed out for the process). It will
now have to check to see if the initializer for a global variable is zero
before it puts it into the .bss section. All "uninitialized" globals
that
it comes across should be handled as external references now, not
variables to stick in the .bss section.
I will update the sparc version of the C frontend tommorow to match these
semantics.
Let me know if this incoherent email confuses you, and I'll try to fix it.
-Chris
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
