Opened 18 months ago

Closed 16 months ago

Last modified 16 months ago

#15058 closed bug (fixed)

scc001 unexpected passes in prof way on CircleCI

Reported by: bgamari Owned by:
Priority: high Milestone: 8.6.1
Component: Compiler Version: 8.2.2
Keywords: ci-breakage Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #10037 Differential Rev(s): Phab:D4712
Wiki Page:

Description (last modified by osa1)

This should supposedly fail due to #10037.

Change History (8)

comment:1 Changed 18 months ago by bgamari

Moreover, it unexpectedly fails in the profasm way:

Actual prof output differs from expected:
--- ./profiling/should_run/scc001.run/scc001.prof.sample.normalised	2018-04-19 14:18:58.342922502 +0000
+++ ./profiling/should_run/scc001.run/scc001.prof.normalised	2018-04-19 14:18:58.342922502 +0000
@@ -1,5 +1,5 @@
 MAIN MAIN <built-in> 0
 (...) Main scc001.hs:16:1-16 1
-h Main scc001.hs:16:1-16 1
 f Main scc001.hs:10:1-7 1
 g Main scc001.hs:13:1-7 1
+h Main scc001.hs:16:1-16 1
*** unexpected failure for scc001(profasm)

comment:2 Changed 18 months ago by bgamari

comment:3 Changed 18 months ago by bgamari

This also fails on i386; see https://circleci.com/gh/ghc/ghc/3655.

comment:4 Changed 18 months ago by bgamari

comment:5 Changed 18 months ago by bgamari

Keywords: ci-breakage added

comment:6 Changed 16 months ago by osa1

Description: modified (diff)
Differential Rev(s): Phab:D4712
Resolution: fixed
Status: newclosed

This was already fixed with c4219d9f7d1, but I realized this too late and actually debugged this. See below for my summary.

This is also not related with #4012 (different optimization parameters will of course give different compiled code) and #12935 (Core outputs are different, not related with object code) so removing those from "related tickets".


The diff is not helpful because it doesn't show the original output and expected files so we miss some context. Basically with -O0 (default, prof way) h is top level and gets a cost centre accordingly, but with -O (profasm way) it's inlined with its SCC.

With -O0 (default, prof way):

h_rsH = scctick<h> case ds_r1I1 of { (h1_a1qY) -> h1_a1qY }

main :: IO ()
main
  = scctick<main>
    >>
      GHC.Base.$fMonadIO
      ($ (print GHC.Show.$fShowBool) (tick<f> GHC.Types.True))
      (>>
         GHC.Base.$fMonadIO
         ($ (print GHC.Show.$fShowInt) (tick<g> GHC.Types.I# 3#))
         ($ (print GHC.Show.$fShowChar) (h_rsH (GHC.Types.C# 'a'#))))

With -O (profasm WAY):

Main.main2
  = scc<main>
    tick<h>
    case Main.main5 of { (h_a1se) ->
    case scc<h> h_a1se Main.main4 of { GHC.Types.C# ds1_a1Zn ->
    case ds1_a1Zn of ds2_a1Zp {
      __DEFAULT ->
        GHC.Types.:
          GHC.Show.$fShowChar3 (GHC.Show.$wshowLitChar ds2_a1Zp Main.main3);
      '\''# -> GHC.Show.$fShowChar1
    }
    }
    }

And profiling outputs are correct in both cases. prof way: (h is a CAF)

COST CENTRE  MODULE                SRC                    no.     entries  %time %alloc   %time %alloc

MAIN         MAIN                  <built-in>             115          0    0.0    1.2     0.0  100.0
 CAF         Main                  <entire-module>        229          0    0.0    0.1     0.0    1.5
  (...)      Main                  scc001.hs:16:1-16      235          1    0.0    0.0     0.0    0.0
  h          Main                  scc001.hs:16:1-16      234          1    0.0    0.0     0.0    0.0
  main       Main                  scc001.hs:(5,1)-(7,23) 230          1    0.0    1.4     0.0    1.4
   f         Main                  scc001.hs:10:1-7       232          1    0.0    0.0     0.0    0.0
   g         Main                  scc001.hs:13:1-7       233          1    0.0    0.0     0.0    0.0

profasm way: (h is inlined, no CAFs for it)

COST CENTRE  MODULE                SRC                    no.     entries  %time %alloc   %time %alloc

MAIN         MAIN                  <built-in>             115          0    0.0    1.2     0.0  100.0
 CAF         Main                  <entire-module>        229          0    0.0    0.1     0.0    0.3
  (...)      Main                  scc001.hs:16:1-16      235          1    0.0    0.0     0.0    0.0
  main       Main                  scc001.hs:(5,1)-(7,23) 230          1    0.0    0.3     0.0    0.3
   g         Main                  scc001.hs:13:1-7       233          1    0.0    0.0     0.0    0.0
   h         Main                  scc001.hs:16:1-16      234          1    0.0    0.0     0.0    0.0

Some ways to fix:

  • If we really want to test this with multiple ways, use two different tests depending on whether the ways add -O or not. Use two different prof.sample files.
  • Only test with ways that add or don't add -O, use single prof.sample.

I don't understand why scc001 is considered as "unexpected pass" in the summary in CircleCI link above. In the logs I see that it actually failed, and I don't see any unexpected passes.

Last edited 16 months ago by osa1 (previous) (diff)

comment:7 Changed 16 months ago by osa1

Description: modified (diff)

comment:8 Changed 16 months ago by osa1

(I was modifying the ticket while also adding a new comment, and accidentally updated the wrong form and updated ticket description. I now reverted it, sorry for the noise)

Note: See TracTickets for help on using tickets.