Displaying 3 results from an estimated 3 matches for "gc_spill".
2016 Feb 05
2
gc relocations on exception path w/RS4GC currently broken
...xample, we're talking about having RS4GC see a GC-safepoint call like so:
%a = _ ; gc pointer
%b = _ ; gc pointer
...
invoke void @callee()
to label %cont unwind label %pad
cont:
_ = %a
...
pad:
landingpad _
_ = %b
...
and transform it into:
%b.gc_spill = alloca <ty>
...
%a = _
%b = _
...
store <ty> %b, <ty>* %b.gc_spill
%sp = invoke token @llvm.experimental.gc.statepoint(<arg list that indicates %a is a gc pointer and %b.gc_spill holds a gc pointer>)
to label %cont unwind label %pad
cont:...
2016 Feb 06
2
gc relocations on exception path w/RS4GC currently broken
...= _ ; gc pointer
> %b = _ ; gc pointer
> ...
> invoke void @callee()
> to label %cont unwind label %pad
> cont:
> _ = %a
> ...
> pad:
> landingpad _
> _ = %b
> ...
>
> and transform it into:
>
> %b.gc_spill = alloca<ty>
> ...
> %a = _
> %b = _
> ...
> store<ty> %b,<ty>* %b.gc_spill
> %sp = invoke token @llvm.experimental.gc.statepoint(<arg list that indicates %a is a gc pointer and %b.gc_spill holds a gc pointer>)
> to...
2016 Jan 22
6
FYI: gc relocations on exception path w/RS4GC currently broken
For anyone following along on ToT using the gc.statepoint mechanism, you
should know that ToT is currently not able to express arbitrary
exceptional control flow and relocations along exceptional edges. This
is a direct result of moving the gc.statepoint representation to using a
token type landingpad. Essentially, we have a design inconsistency
where we expect to be able to