<div dir="ltr">It looks like we only use the block colors when sinking a call out of the loop. That seems like a very uncommon scenario, so maybe we should lazily compute the block colors on demand if we discover that we want to do that transform, rather than eagerly when computing LoopSafetyInfo.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 5, 2017 at 9:49 AM, 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="#0563C1" vlink="#954F72">
<div class="m_5117623034463486556WordSection1">
<p class="MsoNormal">I’ve been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions.  For one thing,
 the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don’t use the coloring information.  Beyond that, it’s called for every loop within LICM even though in many case the information
 won’t have changed since being computed for other loops in the same function.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I was thinking about pulling the funclet coloring out of computeLoopSafetyInfo() and moving it into an analysis pass that can be used by LICM.  Does this sound reasonable?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
<p class="MsoNormal">Andy<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

</blockquote></div><br></div>