<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Peter,<div><br></div><div>Thanks for pointing this out. Some us who are concerned with codegen have discussed the problem. Although the details aren't decided, you can be sure that at the MachineInstr level we won't have a landindpadInst to model liveness of exception values. Any physical registers set by the personality function will be considered live immediately after the call on the unwind path.</div><div><br></div><div>-Andy</div><div><br><div><div>On Aug 4, 2011, at 4:04 PM, Peter Lawrence wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Chris,<div> it is goodness that the LandingpadInst will be pinned to the beginning</div><div>of a BasicBlock,... except for the possibility of PHINode instructions that _must_</div><div>come even earlier.?.</div><div><br></div><div>I can't exactly put my finger on what's going to go wrong with this, </div><div>but it sure smells fishy...</div><div><br></div><div><br></div><div>my current understanding is that the LandingpadInst will "define" some hard</div><div>registers which will be used by following code to switch to the corresponding</div><div>catch-clause</div><div><br></div><div>the lifetimes of these hard registers ostensibly starts at the LandingpadInst,</div><div>but for purposes of PHI lowering and Register Allocation they _must_ actually</div><div>start at the beginning of the BasicBlock -- since that is where control flow will</div><div>return to from the _Unwind_RaiseException / __gcc_personality_v0 calls,</div><div>and it is the _Unwind_ and _personality_ functions that physically set those</div><div>hard registers, not the "LandingpadInst".</div><div><br></div><div>Somehow PHI lowering and register allocation need to be prohibited from</div><div>using those hard registers for spill code at the beginning of a "landing pad block",</div><div>but I don't see how that will "fall out" of the current design.?.</div><div><br></div><div><br></div><div><br></div><div>-Peter Lawrence.</div><div><br></div><div><br></div><div><br></div><div><br><div><div>On Aug 3, 2011, at 12:35 AM, <a href="mailto:llvmdev-request@cs.uiuc.edu">llvmdev-request@cs.uiuc.edu</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Monaco; min-height: 16px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Monaco" size="3" style="font: 12.0px Monaco">I agree with Bill in this case.<span class="Apple-converted-space"> </span>The reason for landingpad to be an instruction is a) make it clear that it is magic in several ways (e.g. pinned to the start of a block), and b) so that LandingPadInst can have a bunch of useful accessors on it.</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Monaco; min-height: 16px; "><br></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Monaco" size="3" style="font: 12.0px Monaco">-Chris</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 12px/normal Monaco; min-height: 16px; "><br></div> </blockquote></div><br></div></div></blockquote></div><br></div></body></html>