Disabling gcc inliner causes WebKit performance regression

[llvmbot]

Bugzilla Link	2353
Resolution	FIXED
Resolved on	Nov 18, 2009 15:50
Version	trunk
OS	All
Depends On	llvm/llvm-bugzilla-archive#4931
Blocks	llvm/llvm-bugzilla-archive#3232
Reporter	LLVM Bugzilla Contributor
CC	@nlewycky

Extended Description

Duncan's patch 51314 regressed WebKit performance by ~5%. I've reverted it for now 51397.

This probably means there were llvm optimizer deficiencies that was covered up by running the gcc inliner. We need to identify and fix them.

[llvmbot]

A bunch of gcc optimizations were turned off. Experimenting with
WebKit shows that indeed the gcc inliner is to thank for the better
performance, and the other optimizations don't matter (for WebKit
at least). I've turned the other ones off again, leaving the
inliner at full throttle. If performance doesn't completely
recover please let me know.

[llvmbot]

Patch 51430 is the one Duncan refers to above.

[llvmbot]

I just took a quick look at this. Disabling gcc inliner still causes about ~5% of performance regression.

Some notable functions are not inlined now:

KJS::ExecState::ExecState (~4% of overall time)
KJS::PropertyMap::~PropertyMap() (~3% of overall time)
KJS::Collector::heapAllocate<(KJS::Collector::HeapType)0>(unsigned long) (~2.7%)

[llvmbot]

Now that llvm-gcc -O2 is inlining more, we no longer see the performance regression.

[lattner]

mentioned in issue llvm/llvm-bugzilla-archive#3232

[efriedma-quic]

mentioned in issue llvm/llvm-bugzilla-archive#4931