[llvm-commits] [llvm] r168893 - in /llvm/trunk: lib/Transforms/Scalar/SimplifyLibCalls.cpp lib/Transforms/Utils/SimplifyLibCalls.cpp test/Transforms/InstCombine/fprintf-1.ll test/Transforms/InstCombine/fputs-1.ll test/Transforms/SimplifyLibCalls/FPuts.ll

[Michael Ilseman]

Meador, I'm also seeing very large compilation time penalties in InstCombine from some of this. In intrinsic-heavy code this can account for up to 40% of InstCombine's time without applying any optimizations.

Intrinsics are Functions in the IR. Do you want to be analyzing intrinsics? If not, then does the attached patch make sense? At the very least, we can exit the expensive analysis early when it doesn't apply.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: skip_intrinsics.patch
Type: application/octet-stream
Size: 1849 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130306/08f7db7e/attachment.obj>
-------------- next part --------------



On Mar 5, 2013, at 3:11 PM, Meador Inge <meadori at codesourcery.com> wrote:

> Hi Nadav,
> 
> On 03/05/2013 04:52 PM, Nadav Rotem wrote:
> 
>> Hi Meador, 
>> 
>> I am now working on improving the clang compile time and I ran into a severe
>> compile time regression in InstCombine and I think that it is due to your
>> LibCallOptimization changes.  The problem is that InstCombiner::visitCallSite()
>> calls LibCallSimplifier::initOptimizations().  InitOptimizations inserts dozens
>> of function names into string map. It rehashes the map and allocates memory very
>> often, and this initialization takes a long time.  I am profiling a typical C++
>> programs that uses STL, and I see lots of functions don't do much beside calling
>> other functions. I already optimized the memory allocation, but not the
>> insertion into the StringMap. On my program, initOptimizations takes 13.5% of
>> the execution time of InstCombine.  I understand that we only initialize this
>> data structure once per function, but many c++ programs have lots of small
>> functions and the cost of initialization is still high. Can you please look into
>> this problem ? 
> 
> Sure.  I will look into it ASAP.  Thanks for the initial investigation.
> 
> 
> -- 
> Meador Inge
> CodeSourcery / Mentor Embedded
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits