[LLVMdev] Interfacing llvm with a precise, relocating GC

Sanjoy Das sanjoy at azulsystems.com
Thu Oct 24 15:42:10 PDT 2013


Hi Rafael, Andrew,

Thank you for the prompt reply.

One approach we've been considering involves representing the
constraint "pointers to heap objects are invalidated at every
safepoint" somehow in the IR itself.  So, if %a and %b are values the
GC is interested in, the safepoint at the back-edge of a loop might
look like:

  ; <label>: body
    %a = phi i32 [ %a.relocated, %body ] [ %a.initial_value, %pred ]
    %b = phi i32 [ %b.relocated, %body ] [ %b.initial_value, %pred ]
    ;; Use %a and %b

    ;; The safepoint starts here
    %a.relocated = @llvm.gc_relocate(%a)
    %b.relocated = @llvm.gc_relocate(%b)
    br %body

This allows us to not bother with relocating derived pointers pointing
inside %a and %b, since it is semantically incorrect for llvm to reuse
them in the next iteration of the loop.  We lower gc_relocate to a
pseudo opcode which lowered into nothing after register allocation.

The problem is, of course, the performance penalty.  Does it make
sense to get the register allocator "see" the gc_relocate instruction
as a copy so that they get the same register / slot?  Will that
violate the intended semantics of gc_relocate (for example, after
assigning the same register / slot to %a and %a.relocated, are there
passes that will try to cache derived pointers across loop
iterations)?

Thanks,
-- Sanjoy





More information about the llvm-dev mailing list