llvm dev - Jan 2017 - WinEH funclet coloring in computeLoopSafetyInfo

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/20170105/0448f85f/attachment.html>

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>
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/5ba55215/attachment.html>

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>