[PATCH] Inliner Enhancement
Xinliang David Li
xinliangli at gmail.com
Wed Mar 18 22:22:41 PDT 2015
On Wed, Mar 18, 2015 at 4:09 AM, 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.
> About your benchmarks, they're very promising numbers. Taking 3% code-size
> for 1.5% performance is not a bad choice.
I agree with this size/performance trade-off ;)
> Have you tested/benchmarked in other arches? Would be good to know at
> least on x86_64 and ARM how that goes.
> I'll see if I can run those same tests on ARM, at least.
> rL LLVM
> EMAIL PREFERENCES
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits