#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 Difficulty: Unknown
Test Case: profiling/should_run/profinline001 Blocked By:
Blocking: Related Tickets:

Description

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
    where
        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 test.prof

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 23 months 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 22 months 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 22 months 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 22 months ago by igloo

Would a NO_SCC pragma also make sense?

comment:5 Changed 22 months 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 22 months ago by marlowsd@…

commit 6181e007f0e1e8eddba7acf0d5fbcbaf46806249

Author: Simon Marlow <marlowsd@gmail.com>
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
    though.

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

comment:7 Changed 22 months 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 22 months ago by pcapriotti

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