[PATCH] Inliner Enhancement

[Jiangning Liu]

Hi Renato,

2015-03-18 19:09 GMT+08:00 Renato Golin <renato.golin at linaro.org>:

> Hi Jiangning,
>
> AFAICT, your design considerations are sound and relevant.
>
> The "ABC problem" seems nasty. Without much thinking, could you use a lazy
> evaluation by annotating code with metadata stating the current threshold
> for that particular BB/Loop? If instead of passing through the code
> multiple times (for ABC and ABD, etc), you could memoize the info in a
> graph-like metadata, so that you could re-use partial calculations in
> future inlinings. It may not be worth it, but if reading from this metadata
> is quicker than re-calculating, that it'd at least be faster. Also, such
> metadata could (should?) be quickly discarded anyway, as after inlining,
> the costs will change.
>

Yeah, agree with you. This is a piece of logic we can improve for
compile-time. But essentially I also agree with David, using new pass
manager should be able to partially solve the issue.


>
> About your benchmarks, they're very promising numbers. Taking 3% code-size
> for 1.5% performance is not a bad choice. Have you tested/benchmarked in
> other arches? Would be good to know at least on x86_64 and ARM how that
> goes.
>

I just checked it on my x86 box, the performance impact of SPEC2000 is
+0.85%.

Thanks,
-Jiangning


>
> I'll see if I can run those same tests on ARM, at least.
>
> cheers,
> --renato
>
>
> REPOSITORY
>   rL LLVM
>
> http://reviews.llvm.org/D8408
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150319/816c4b4e/attachment.html>