Ticket #6131 (closed bug: fixed)

Opened 12 months ago

Last modified 11 months ago

-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

Changed 12 months ago by simonmar

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

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?

Changed 11 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.

Changed 11 months ago by simonmar

  • priority changed from normal to high
  • status changed from infoneeded to new
  • component changed from Compiler to Profiling
  • milestone set to 7.6.1

Seems reasonable. I'll look into fixing it.

Changed 11 months ago by igloo

Would a NO_SCC pragma also make sense?

Changed 11 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.

Changed 11 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(-)

Changed 11 months ago by simonmar

  • status changed from new to merge
  • testcase set to profiling/should_run/profinline001
  • milestone changed from 7.6.1 to 7.4.3

Changed 11 months ago by pcapriotti

  • status changed from merge to closed
  • resolution set to fixed

Merged as 87ef70b838f43c6425bea97c9a791f2d0bf35e5c.

Note: See TracTickets for help on using tickets.