[llvm-dev] WinEH funclet coloring in computeLoopSafetyInfo

[Kaylor, Andrew via llvm-dev]

That seems reasonable.  I’ll see if I can collect some information on how much time this is currently taking and how often it’s actually needed.  I’ve been working with a benchmark that I think will provide a decent test case.

From: Reid Kleckner [mailto:rnk at google.com]
Sent: Tuesday, January 10, 2017 3:13 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com>
Cc: Michael Kuperstein <mkuper at google.com>; llvm-dev at lists.llvm.org
Subject: Re: WinEH funclet coloring in computeLoopSafetyInfo

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.

On Thu, Jan 5, 2017 at 9:49 AM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:
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.

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?

Thanks,
Andy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170110/6296d8e2/attachment.html>