it is goodness that the LandingpadInst will be pinned to the beginning
of a BasicBlock,… except for the possibility of PHINode instructions that must
come even earlier.?.
I can’t exactly put my finger on what’s going to go wrong with this,
but it sure smells fishy…
my current understanding is that the LandingpadInst will “define” some hard
registers which will be used by following code to switch to the corresponding
the lifetimes of these hard registers ostensibly starts at the LandingpadInst,
but for purposes of PHI lowering and Register Allocation they must actually
start at the beginning of the BasicBlock – since that is where control flow will
return to from the _Unwind_RaiseException / __gcc_personality_v0 calls,
and it is the Unwind and personality functions that physically set those
hard registers, not the “LandingpadInst”.
Somehow PHI lowering and register allocation need to be prohibited from
using those hard registers for spill code at the beginning of a “landing pad block”,
but I don’t see how that will “fall out” of the current design.?.