[llvm-dev] Saving Compile Time in InstCombine

Hal Finkel via llvm-dev
Sat, 18 Mar 2017 00:49:18 -0000

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>