Opened 4 years ago

Closed 3 years ago

#6131 closed bug (fixed)

-fprof-auto adds cost centers to INLINE functions

Reported by: akio Owned by:
Priority: high Milestone: 7.4.3
Component: Profiling Version: 7.4.2-rc1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case: profiling/should_run/profinline001
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


According to the Section 5.2 of User's Guide, -fprof-auto should add cost centers only to functions that are not marked INLINE. However GHC 7.4 doesn't respect this.

A simple example:

foo :: Integer -> Integer
foo x = x + 100
{-# INLINE foo #-}

main = print $ loop (10000000::Int) 10000000000000000000000
        loop 0 x = x
        loop n x = loop (n-1) (foo x)

Compile and run this like:

% ghc -prof -fprof-auto -O2 test.hs
% ./test +RTS -p
% grep foo

And you will see 'foo' is listed as a cost center.

This happens with GHC 7.4.1 and 7.4.2-rc1

Change History (8)

comment:1 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Status changed from new to infoneeded

This is indeed a bug, however we are inclined to fix the documentation rather than the implementation, i.e. functions with an INLINE pragma will also get cost centres. Would this be a problem for you? What is the reason that you didn't want a cost centre on foo?

comment:2 Changed 3 years ago by akio

I used to use an INLINE pragma as a handy way to prevent a cost center from being added to a function. Most of the time I wanted this feature because adding a cost center to a frequently-called small function tends to distort profiling results by adding a significant cost to that function, including costs of lost optimizations.

comment:3 Changed 3 years ago by simonmar

  • Component changed from Compiler to Profiling
  • Milestone set to 7.6.1
  • Priority changed from normal to high
  • Status changed from infoneeded to new

Seems reasonable. I'll look into fixing it.

comment:4 Changed 3 years ago by igloo

Would a NO_SCC pragma also make sense?

comment:5 Changed 3 years ago by simonmar

Yes, NO_SCC would make sense. However, it turns out that adding SCCs to INLINE functions exposes another bug elsewhere that is harder to fix, so I'm going to do as originally suggested and not add SCCs to INLINE functions.

comment:6 Changed 3 years ago by marlowsd@…

commit 6181e007f0e1e8eddba7acf0d5fbcbaf46806249

Author: Simon Marlow <[email protected]>
Date:   Fri Jun 15 10:30:35 2012 +0100

    Don't put auto sccs on INLINE functions (#6131)
    There was also a bug caused by INLINEs getting SCCs, but unfortunately
    I have lost the test case.  The Note in the code describes the problem

 compiler/deSugar/Coverage.lhs |   36 +++++++++++++++++++++++++++++++++---
 1 files changed, 33 insertions(+), 3 deletions(-)

comment:7 Changed 3 years ago by simonmar

  • Milestone changed from 7.6.1 to 7.4.3
  • Status changed from new to merge
  • Test Case set to profiling/should_run/profinline001

comment:8 Changed 3 years ago by pcapriotti

  • Resolution set to fixed
  • Status changed from merge to closed
Note: See TracTickets for help on using tickets.