[llvm] r207713 - Patch for function cloning to inline all blocks whose address is taken

[Gerolf Hoflehner]

O3 flto compile time I measured for the llvm test suite (and other benchmarks) looked fine. The biggest jump I had seen was a > 6% increase for a SPEC’95 benchmark (perl), which went away in a rerun. Also the perl benchmark in CINT2000 and CINT2006 did not show any compile-time regression. 

I can’t say for sure that there is no compile-time impact. My measurement setup is not perfect even though I run single thread, set the proper states etc,
but there is still a lot of compile-time variability from run to run especially on the fast compiles. More importantly my setup has no track record of finding a regression
yet and I won’t attribute this to my high quality coding :-). But I”m positive there can’t be a big impact from this patch.
If you notice any issues due to unduly increased clone time please let me know.

Cheers
Gerolf


On Apr 30, 2014, at 7:38 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Wed, Apr 30, 2014 at 3:05 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote:
> Patch for function cloning to inline all blocks whose address is taken
> 
> Not all address taken blocks get inlined. The reason is
> that a blocks new address is known only when it is cloned. But e.g.
> a branch instruction in a different block could need that address earlier
> while it gets cloned. The solution is to collect the set of all
> blocks that can potentially get inlined and compute a new block address
> up front. Then clone and cleanup.
> 
> This could introduce a lot of compile time overhead. Did you measure anything to check for that? The problem is that basic blocks are a reasonably sparse linked list, so walking them twice is a lot of cache churning.
> 
> As an alternative (that also shouldn't have the problem with pruning), did you consider storing the set of block addresses which need to be updated, and fix those operands after you finish cloning?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140505/7bca17cb/attachment.html>