<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
Guys,<div> on second thought...</div><div><br></div><div>doesn't making the exception registers live from the InvokeInst to the LandingpadInst</div><div>create problems for critical-edge-splitting ?</div><div><br></div><div>if a landingpad-edge is critical and needs to be split, won't we be creating and inserting</div><div>a new BB between the "invoke-block" and the "landingpad-block", and if we do then</div><div>isn't there the possibility of the register allocator spilling the contents of the exception</div><div>registers from within the newly created block --- but this block won't ever get executed</div><div>because the _Unwind_ / _personality_ functions will cause control flow to go directly</div><div>to the block with the LandingpadInst ? If you really want to split a landingpad-edge</div><div>won't you have to move the LandingpadInst up into the new block ?</div><div><br></div><div>if this is true (and I seem to be making a lot of logic errors lately, so maybe reread and</div><div>proof-read the above a few times...!...) then don't we need to add another invariant to</div><div>Bill's list:</div><div><br></div><div>*) there can be no code between an InvokeInst and its LandingpadInst other than</div><div>possibly PHINodes at the beginning of the landingpad-block.</div><div><br></div><div><br></div><div>It seems that if you really do need to split a landingpad-edge then you have to move</div><div>the LandingpadInst up into (the beginning of) the new block.</div><div><br></div><div>However it seems that if a landingpad-block has multiple predecessors (often the case,</div><div>multiple InvokeInst in the main body of a try-statement all go to the same landingpad-</div><div>block), then you cannot move the LandingpadInst in order to break a critical edge unless</div><div>you do it for _all_ landingpad-block predecessor edges simultaneously, but that seems</div><div>to be a messy conclusion (being forced to split other edges that don't need to be split).</div><div><br></div><div><br></div><div>my first guess is that all the nuances of whether it ever makes sense and/or is even</div><div>logically possible to split a critical landingpad-edge won't be discovered except by</div><div>painful trial-and-error, and that it might be best to at first disallow it until proven doable</div><div>by someone working in an isolated branch -- although proving it works may be difficult,</div><div>since so little code actually uses exceptions (only TableGen in llvm ?).</div><div><br></div><div><br></div><div>-Peter Lawrence.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><div>On Aug 4, 2011, at 4:16 PM, Andrew Trick wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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></blockquote></div><br></div></body></html>