<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 13, 2015 at 7:11 AM, Joseph Tremoulet <span dir="ltr"><<a href="mailto:jotrem@microsoft.com" target="_blank">jotrem@microsoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Yes, it seems like WinEHPrepare should always be able to move landing pad code to somewhere appropriate.  Even if there's some involved code to handle the cases
 that force #1, it's great that the complexity is contained in WinEHPrepare.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I'm still confused about the apparent lack of constraints after WinEHPrepare. 
<b>Can we simply require/assume that WinEHPrepare be run after any passes that may move/insert code into landing pads?  Is that documented somewhere?</b></span></p></div></div></blockquote><div><br></div><div>Yeah, this is kind of fuzzy. EH preparation just happens very late, after all the interesting passes (sroa, inlining, etc) have run. There are some passes that run afterwards, but they are typically lowering passes, and won't do this kind of hoisting.</div></div></div></div>