search for: gc_reloc

...he 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...

On Oct 24, 2013, at 2:50 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: >> Hello llvm-dev! >> >> My colleages and I are currently evaluating llvm's suitability as a >> JIT compiler interfacing with a precise, relocating garbage collector. >> While we

...ht > 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. This is the right genera...

...> ; <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. >...

...> ; <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. &g...

...> ; <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. &g...

...%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 >>&g...

...ome/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1133:1: current parser token 'LISP' 2. /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1097:6: LLVM IR generation of declaration 'gc_relocate' 3. /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1097:6: Generating code for declaration 'gc_relocate' 4. /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1098:1: LLVM IR...

...lave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1133:1: > current parser token 'LISP' > 2. > /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1097:6: > LLVM IR generation of declaration 'gc_relocate' > 3. > /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/siod/slib.c:1097:6: > Generating code for declaration 'gc_relocate' > 4. > /home/baldrick/osuosl/slave/clang-x86_64-debian-fnt/test-suite.src/MultiSource/Applications/...

...er we simply deprecate the existing gcroot support and target it for complete removal a couple of releases down the road.. * What programmatic interface should we present at the IR level and where should it live? We're moving towards a CallSite like interface for statepoints, gc_relocates, and gc_results call sites. Is this the right approach? If so, should it live in the IR subtree, or Support? (Note: The current code is only about 40% migrated to the new interface.) * To support invokable calls with safepoints, we need to make the statepoint intrinsic invo...

...uld prefer we simply deprecate the existing gcroot support and target it for complete removal a couple of releases down the road.. >> • What programmatic interface should we present at the IR level and where should it live? We're moving towards a CallSite like interface for statepoints, gc_relocates, and gc_results call sites. Is this the right approach? If so, should it live in the IR subtree, or Support? (Note: The current code is only about 40% migrated to the new interface.) >> • To support invokable calls with safepoints, we need to make the statepoint intrinsic invokable....