example program about llvm-statepoint-utils HOT 4 CLOSED

Take a look at doGC in test/driver.c. The loop in there is walking a contiguous call stack and relocating pointers in the frame (which are assumed to be i32* for the example).

from llvm-statepoint-utils.

i get an error using make in the test folder

        llc fib.ll -o fib.s
perl -i -pe "s/__LLVM_StackMaps:/.globl __LLVM_StackMaps\n__LLVM_StackMaps:/" fib.s
gcc -c fib.s -o fib.o
fib.s: Assembler messages:
fib.s:1: Error: character following name is not '#'
fib.s:2: Error: unknown pseudo-op: `.macosx_version_min'
fib.s:93: Error: character following name is not '#'
fib.s:99: Error: character following name is not '#'
fib.s:104: Error: character following name is not '#'
fib.s:231: Error: unknown pseudo-op: `.subsections_via_symbols'

EDIT, i had to remove the target triple from the .ll file

the gc always copies the value even if it already copied it before, doesnt this give a lot of the same items on the heap if multiple roots refer to the same value

from llvm-statepoint-utils.

moving the heapPtr and heapBase to driver.c causes the program to crash.

from llvm-statepoint-utils.

Thanks for the heads up: I removed the target triple so it works on other platforms.

the gc always copies the value even if it already copied it before, doesnt this give a lot of the same items on the heap if multiple roots refer to the same value

Yes it would in this example, but it would be necessary if those heap objects are mutable. For immutable objects, a non-toy GC could implement a form of hash consing to common-up those objects, but I personally think it's not worth the cost for most programs.

from llvm-statepoint-utils.