[LLVMdev] A working garbage collector - finally :)

[Reid Kleckner]

Where's the problem?  A pointer to v's alloca escapes to llvm.gcroot,
so the optimizers should know that foo could modify the value it
holds.  foo() might also read v[i] through the escaped pointer, so the
store will have to happen before the call.

Reid

2011/3/8 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>:
> Since you are using a copying collector, may I ask how do you handle
> registers holding pointers to intermediate values?
>
> The example I am considering is something like
>
> void foo(void);
> void f(long long *v, long long n) {
>   long long int i;
>   for (i = 0; i < n; ++i) {
>     v[i] = i;
>     foo();
>   }
> }
>
> If *v points to gc memory, we can start the function with
>
> %v.addr = alloca i64*, align 8
> %foobar = bitcast i64** %v.addr to i8**
> call void @llvm.gcroot(i8** %foobar, i8* null)
> store i64* %v, i64** %v.addr, align 8
>
> but nothing prevents llvm from putting the call to foo in between the
> computation of &v[i] and the store by using a callee saved register. If
> GC moves moves v during the call to foo, the next store will be wrong.
>
>> -- Talin
>>
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>