[PATCH] D15393: [X86] Order the local stack symbols to improve code size and locality.

Gerolf Hoflehner via llvm-commits llvm-commits at lists.llvm.org
Wed Feb 17 21:00:14 PST 2016


Hi Zia,

do you have HSW performance numbers for this change? An internal bot is logging a >10% regression for MultiSource/Benchmarks/Ptrdist/ks/ks <https://smooshbase.apple.com/perf/db_default/v4/nts/graph?highlight_run=114068&plot.746=313.746.3> (O3 flto) pinned to this change. If you can reproduce it perhaps there is a tuning opportunity. 

Thanks!
Gerolf


> On Dec 9, 2015, at 1:29 PM, Zia Ansari via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> zansari created this revision.
> zansari added reviewers: rnk, qcolombet, mkuper.
> zansari added a subscriber: llvm-commits.
> Herald added subscribers: qcolombet, MatzeB.
> 
> These changes introduce a local stack symbol table ordering phase to allow all targets a chance to order the stack symbols the way they'd like it.
> 
> X86 heuristics are added to order the symbols to improve code size and locality. The current default behavior for all other targets is to leave the order untouched. Other target specific heuristics can be very easily applied by simply providing the necessary heuristics.
> 
> As an example, here are some cpu2000 code size improvements that I measured (mileage may vary depending on options used).. Numbers are percentage reduction in the sum of the text size of all objects:
> 
> 177.mesa	1.81%
> 179.art	0.50%
> 183.equake	1.78%
> 188.ammp	3.75%
> 164.gzip	0.79%
> 175.vpr	0.85%
> 176.gcc	0.70%
> 181.mcf	0.26%
> 186.crafty	0.47%
> 197.parser	0.29%
> 252.eon	2.47%
> 253.perl	0.47%
> 254.gap	0.55%
> 255.vortex	1.14%
> 256.bzip2	0.64%
> 300.twolf	0.88%
> total	1.24%
> 
> I measured performance on cpu2k, cpu2006, eembc, and a few other benchmarks and it was pretty much flat, although on average, these changes should also improve data locality.
> 
> Many lit changes broke due to new offsets being assigned to local symbols. I fixed these by disabling the optimization (vs. updating with new offsets) so that we'd avoid additional flakiness due to heuristic tuning.
> 
> 
> http://reviews.llvm.org/D15393
> 
> Files:
>  include/llvm/CodeGen/CommandFlags.h
>  include/llvm/Target/TargetFrameLowering.h
>  include/llvm/Target/TargetOptions.h
>  lib/CodeGen/PrologEpilogInserter.cpp
>  lib/Target/X86/X86FrameLowering.cpp
>  lib/Target/X86/X86FrameLowering.h
>  test/CodeGen/X86/2009-02-12-DebugInfoVLA.ll
>  test/CodeGen/X86/aligned-variadic.ll
>  test/CodeGen/X86/cleanuppad-realign.ll
>  test/CodeGen/X86/dynamic-allocas-VLAs.ll
>  test/CodeGen/X86/hipe-cc.ll
>  test/CodeGen/X86/hipe-cc64.ll
>  test/CodeGen/X86/local-stack-symbol-ordering.ll
>  test/CodeGen/X86/phys-reg-local-regalloc.ll
>  test/CodeGen/X86/seh-catch-all-win32.ll
>  test/CodeGen/X86/seh-stack-realign.ll
>  test/CodeGen/X86/ssp-data-layout.ll
>  test/CodeGen/X86/statepoint-stack-usage.ll
>  test/CodeGen/X86/statepoint-stackmap-format.ll
>  test/CodeGen/X86/stdarg.ll
>  test/CodeGen/X86/widen_load-1.ll
>  test/CodeGen/X86/win-catchpad-varargs.ll
>  test/CodeGen/X86/win-catchpad.ll
>  test/CodeGen/X86/win32-seh-catchpad-realign.ll
> 
> <D15393.42317.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160217/224749f2/attachment.html>


More information about the llvm-commits mailing list