<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 3, 2014 at 2:13 PM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.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">Hi Reid,<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 saw your patch but haven’t looked closely at it yet.<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 do have a work in progress for the outlining.  I expect to have something ready to share pretty soon, hopefully by the end of the week.  It won’t be ready
 for primetime, as it’s making a whole lot of assumptions about the structure of the IR, but I think it will work with a sample IR file based on what you posted in your earlier SEH review.  I expect that it will be a useful point of reference for discussion
 and that I should be able to quickly refactor it into something product ready once we’ve ironed out the expectations as to what the incoming IR will look like and how flexible the heuristics for identifying regions to outline need to be.</span></p></div></div></blockquote><div><br></div><div>Nice. Sounds like I should move forward on the SEH patch, which assumes that filters are pre-outlined, and move on to @llvm.outlined_handlers to outlined __finally blocks next. Basically, teach CodeGen how to emit SEH tables for IR that is already in the outlined form.</div><div>  </div><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"></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">One thing that I’ve discussed with a co-worker but haven’t explored in my implementation yet is the possibility of using CodeExtractor to do the outlining rather
 than basing it on the CloneFunction stuff.  My current implementation is based on CloneAndPruneFunctionInto as you suggested, but I wondered if CodeExtractor might not be a better starting point.  What do you think?</span></p></div></div></blockquote><div><br></div><div>Hm, I wasn't aware of CodeExtractor. It looks like it basically reparents basic blocks and fixes up the SSA graph. This is efficient, but I don't think it will work if a BB is reachable by two landing pads. A BB can't be extracted twice, but it can be cloned twice. Also, CodeExtractor can't extract invokes. I would stick to cloning for now, and add extraction later as an optimization.</div><div> </div><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"></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Also, at the moment I’m more or less ignoring the frame variable issue.  My ValueMaterializer is just creating new allocas with the name I want.  I think that
 will be easy enough to patch up once your llvm.frameallocate stuff is in place.  The implication of this is that right now I’m not looking for live variables before I start outlining, I’m just picking them up as I go.  It seems like that may need to change.</span></p></div></div></blockquote></div></div></div>