[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]

On Mar 7, 2013, at 6:55 AM, Meador Inge <meadori at codesourcery.com> wrote:

> On 03/06/2013 02:10 PM, Michael Ilseman wrote:
> 
>> 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?
> 
> Actually, I just remembered that we do fold a few intrinsics.
> Namely: llvm.pow.f32, llvm.pow.f64, llvm.pow.f80, llvm.pow.f128,
> llvm.pow.ppcf128, llvm.exp2.ppcf128, llvm.exp2.f128, llvm.exp2.f80,
> llvm.exp2.f64, and llvm.exp2.f32.
> 

The patch was exiting early in:
  getAllocationData()
  isFreeCall()
  tryOptimizeCall()

Are getAllocationData() and isFreeCall() early exit valid? They show up as 10% and 7% of InstCombine respectively in "intrinsic heavy" code, where heavy means 25% comprised of intrinsics. Are you ok with me applying those two?

As far as tryOptimizeCall(), which is 20% in my profile, can you make a fast check for whether the call is even a libcall/pow/exp2? That should also benefit Nadav, who is seeing wrapper functions of non-libcalls.


> So please don't apply this patch.  I am working on the performance regression
> now and hope to have a patch out this week.
> 

Thanks! These suggestions are meant to be in addition to your improvements to the core algorithm.

> -- 
> Meador Inge
> CodeSourcery / Mentor Embedded