search for: gc_reload

...;arg list that indicates %a is a gc pointer and %b.gc_spill holds a gc pointer>) to label %cont unwind label %pad cont: %a.reloc = call <ty> @llvm.experimental.gc.relocate(token %sp, <index of %a>, <index of %a>) _ = %a.reloc ... pad: landingpad _ %b.gc_reload = load <ty>, <ty>* %b.gc_spill _ = %b.gc_reload ... which would then get lowered to a call with a stack map reporting %a (or the slot that lowering spills %a to) and %b.gc_spill as holding live gc pointers. Issue #1: obscurability of the %b.gc_spill use on the gc.statepoint inv...

...d %b.gc_spill holds a gc pointer>) > to label %cont unwind label %pad > cont: > %a.reloc = call<ty> @llvm.experimental.gc.relocate(token %sp,<index of %a>,<index of %a>) > _ = %a.reloc > ... > pad: > landingpad _ > %b.gc_reload = load<ty>,<ty>* %b.gc_spill > _ = %b.gc_reload > ... > > which would then get lowered to a call with a stack map reporting %a (or the slot that lowering spills %a to) and %b.gc_spill as holding live gc pointers. > > > Issue #1: obscurability of the %b.gc_sp...

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