[PATCH] Inliner Enhancement

[Renato Golin]

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. 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.

cheers,
--renato


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D8408

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/