Vassil Vassilev 846aac852c Assert that the reference came from the static initializers and upgrade the test.
The compiled code is unloaded by iterating the AST out of which the compiled code
came. The problem is that C++ supports static initialization. For example:
int a = 5; on the global scope means set the value of a to 5 before the program
starts. To support that clang implicitly generates functions that enforce the
expected initialization order. That can become easily very complex. Let's see
a more "real-life" example:

int f() { printf("I am f()"); return 0; }
int a = f();

Besides the code for a and f clang will emit:
define internal void @__cxx_global_var_init() section "__TEXT,__StaticInit,regular,pure_instructions" {
entry:
  %0 = call i32 @__cxa_atexit(void (i8*)* bitcast (void (%"struct.cling::runtime::internal::__trigger__cxa_atexit"*)* @_ZN5cling7runtime8internal21__trigger__cxa_atexitD1Ev to void (i8*)*), i8* getelementptr inbounds (%"struct.cling::runtime::internal::__trigger__cxa_atexit"* @_ZN5cling7runtime8internal1SE, i32 0, i32 0), i8* @__dso_handle) #1
  ret void
}
define internal void @_GLOBAL__I_a() section "__TEXT,__StaticInit,regular,pure_instructions" {
entry:
  call void @__cxx_global_var_init()
  ret void
}

and more importantly:

define internal void @__cxx_global_var_init1() section "__TEXT,__StaticInit,regular,pure_instructions" {
entry:
  %call = call i32 @_Z1fv() ; THAT IS A REFERENCE TO f()
  store i32 %call, i32* undef, align 4
  ret void
}

So when iterating the AST and trying to remove f(), we cannot because it is still
referenced by __cxx_global_var_init1. However we know this is not an issue,
because that __cxx_global_var_init1 was meant to be executed only once and that
already happened. So in first approximation we could drop the references of f
in __cxx_global_var_init1 and remove the rest.
2013-10-29 20:19:12 +01:00
..
2013-10-17 12:38:55 +02:00
2013-10-14 09:11:39 +02:00
2013-07-21 15:16:57 +02:00