[llvm-dev] Saving Compile Time in InstCombine

[Hal Finkel via llvm-dev]

On 03/17/2017 04:30 PM, Mehdi Amini via llvm-dev wrote:
>
>> On Mar 17, 2017, at 11:50 AM, Mikhail Zolotukhin via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Hi,
>>
>> One of the most time-consuming passes in LLVM middle-end is 
>> InstCombine (see e.g. [1]). It is a very powerful pass capable of 
>> doing all the crazy stuff, and new patterns are being constantly 
>> introduced there. The problem is that we often use it just as a 
>> clean-up pass: it's scheduled 6 times in the current pass pipeline, 
>> and each time it's invoked it checks all known patterns. It sounds ok 
>> for O3, where we try to squeeze as much performance as possible, but 
>> it is too excessive for other opt-levels. InstCombine has an 
>> ExpensiveCombines parameter to address that - but I think it's 
>> underused at the moment.
>
> Yes, the “ExpensiveCombines” has been added recently (4.0? 3.9?) but I 
> believe has always been intended to be extended the way you’re doing 
> it. So I support this effort :)

+1

Also, did your profiling reveal why the other combines are expensive? 
Among other things, I'm curious if the expensive ones tend to spend a 
lot of time in ValueTracking (getting known bits and similar)?

  -Hal

>
> CC: David for the general direction on InstCombine though.
>
>
> —
> Mehdi
>
>
>
>>
>> Trying to find out, which patterns are important, and which are rare, 
>> I profiled clang using CTMark and got the following coverage report:
>> <InstCombine_covreport.html>
>> (beware, the file is ~6MB).
>>
>> Guided by this profile I moved some patterns under the "if 
>> (ExpensiveCombines)" check, which expectedly happened to be neutral 
>> for runtime performance, but improved compile-time. The testing 
>> results are below (measured for Os).
>>
>> Performance Improvements - Compile Time 	Δ 	Previous 	Current 	σ
>> CTMark/sqlite3/sqlite3 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.15=2> 	-1.55% 
>> 6.8155 	6.7102 	0.0081
>> CTMark/mafft/pairlocalalign 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.1=2> 	-1.05% 
>> 8.0407 	7.9559 	0.0193
>> CTMark/ClamAV/clamscan 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.7=2> 	-1.02% 
>> 11.3893 	11.2734 	0.0081
>> CTMark/lencod/lencod 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.10=2> 	-1.01% 
>> 12.8763 	12.7461 	0.0244
>> CTMark/SPASS/SPASS 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.5=2> 	-1.01% 
>> 12.5048 	12.3791 	0.0340
>>
>>
>> Performance Improvements - Compile Time 	Δ 	Previous 	Current 	σ
>> External/SPEC/CINT2006/403.gcc/403.gcc 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.14=2> 	-1.64% 
>> 54.0801 	53.1930 	-
>> External/SPEC/CINT2006/400.perlbench/400.perlbench 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.7=2> 	-1.25% 
>> 19.1481 	18.9091 	-
>> External/SPEC/CINT2006/445.gobmk/445.gobmk 
>> <http://michaelsmacmini.local/perf/v4/nts/2/graph?test.15=2> 	-1.01% 
>> 15.2819 	15.1274 	-
>>
>>
>>
>> Do such changes make sense? The patch doesn't change O3, but it does 
>> change Os and potentially can change performance there (though I 
>> didn't see any changes in my tests).
>>
>> The patch is attached for the reference, if we decide to go for it, 
>> I'll upload it to phab:
>>
>> <0001-InstCombine-Move-some-infrequent-patterns-under-if-E.patch>
>>
>>
>> Thanks,
>> Michael
>>
>> [1]: http://lists.llvm.org/pipermail/llvm-dev/2016-December/108279.html
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170317/01fcada7/attachment.html>