Skip to content
Snippets Groups Projects

Improve demand analysis for join points

    • Closed Issue created by Simon Peyton Jones @simonpj

    Consider

       g :: (Int,Int) -> Int
   g (p,q) = p+q

   f :: Int -> Int -> Int
   f x p = g (join j y = (p,y)
              in case x of
                   True  -> j 3
                   False -> j 4)

    If j was a vanilla function definition, we'd analyse its body with evalDmd, and think that it was lazy in p.

    But for a join point we can do better. We know that j's body (if evaluated at all) will be evaluated with the demand that consumes the entire join-binding, in this case the argument demand from g. Whizzo! g evaluates both components of its arugment pair, so j is strict in p.

    So, when analysing a join point, we can analyse its body with the demand from the entire join-binding. Another win for join points!

    Trac metadata
    Trac field Value
    Version 8.0.1
    Type Bug
    TypeOfFailure OtherFailure
    Priority normal
    Resolution Unresolved
    Component Compiler
    Test case
    Differential revisions
    BlockedBy
    Related
    Blocking
    CC
    Operating system
    Architecture
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    • Simon Peyton Jones changed weight to 5

      changed weight to 5

    • Simon Peyton Jones added Tbug Trac import labels

      added Tbug Trac import labels

    • Simon Peyton Jones added join points label

      added join points label

    • Simon Peyton Jones mentioned in commit b5b7d820

      mentioned in commit b5b7d820

    • Simon Peyton Jones closed

      closed

    • Simon Peyton Jones
      Simon Peyton Jones @simonpj ·
      Author Developer

      Done. No visible effect on nofib, but still good.

      Trac metadata
      Trac field Value
      Resolution Unresolved → ResolvedFixed
    • Alp Mestanogullari
      Alp Mestanogullari @alp ·
      Owner

      When running ./validate --slow, I found out that the T13543 test fails with all 3 of these ways: hpc, optasm, optllvm.

      =====> T13543(hpc) 1 of 1 [0, 0, 0]
cd "./simplCore/should_compile/T13543.run" &&  "/home/alp/ghc/inplace/test   spaces/ghc-stage2" -c T13543.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O -fhpc -ddump-str-signatures
Actual stderr output differs from expected:
diff -uw "./simplCore/should_compile/T13543.run/T13543.stderr.normalised" "./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised"
--- ./simplCore/should_compile/T13543.run/T13543.stderr.normalised	2018-03-08 14:13:19.867965000 +0100
+++ ./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised	2018-03-08 14:13:19.867965000 +0100
@@ -1 +1,12 @@
  
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><L,1*U><L,1*U>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
+
+
+
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><L,1*U><L,1*U>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
*** unexpected failure for T13543(hpc)
      =====> T13543(optasm) 1 of 1 [0, 0, 0]
cd "./simplCore/should_compile/T13543.run" &&  "/home/alp/ghc/inplace/test   spaces/ghc-stage2" -c T13543.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O -fasm -ddump-str-signatures
Actual stderr output differs from expected:
diff -uw "./simplCore/should_compile/T13543.run/T13543.stderr.normalised" "./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised"
--- ./simplCore/should_compile/T13543.run/T13543.stderr.normalised	2018-03-08 14:16:02.367965000 +0100
+++ ./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised	2018-03-08 14:16:02.367965000 +0100
@@ -1 +1,12 @@
  
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
+
+
+
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
*** unexpected failure for T13543(optasm)
      =====> T13543(optllvm) 1 of 1 [0, 0, 0]
cd "./simplCore/should_compile/T13543.run" &&  "/home/alp/ghc/inplace/test   spaces/ghc-stage2" -c T13543.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output  -O -fllvm -ddump-str-signatures
Actual stderr output differs from expected:
diff -uw "./simplCore/should_compile/T13543.run/T13543.stderr.normalised" "./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised"
--- ./simplCore/should_compile/T13543.run/T13543.stderr.normalised	2018-03-08 14:16:28.627965000 +0100
+++ ./simplCore/should_compile/T13543.run/T13543.comp.stderr.normalised	2018-03-08 14:16:28.627965000 +0100
@@ -1 +1,12 @@
  
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
+
+
+
+==================== Strictness signatures ====================
+Foo.$trModule: m
+Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
+Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
*** unexpected failure for T13543(optllvm)

      In all 3 cases, we're expecting an empty stderr (that we get with other ways like normal) but we instead get the strictness signatures dumped there, because of the flag that we pass to ghc:

      test('T13543', normal, compile, ['-ddump-str-signatures'])

      Should I just strip that flag so that these tests pass? It's still odd that say normal and optasm dump things in different places, isn't it?

    • Ben Gamari
      Ben Gamari @bgamari ·
      Maintainer

      Hmm, I think the expected test output might just be wrong: the stderr output is empty in the normal way because GHC is invoked without optimisation enabled in that way. I believe the test was supposed to expect non-empty output.

      I suspect we should only be running this test in the optasm way (since the other ways will inevitably differ in their strictness signatures) and update the output accordingly. We should ask Simon to look over the new output before committing.

    • Alp Mestanogullari
      Alp Mestanogullari @alp ·
      Owner

      OK, I'll include this change in my WIP testsuite expectations changes patch and ask Simon about the "new" expected output (see below for the program & output).

      {-# LANGUAGE RankNTypes, GADTs #-}

module Foo where

g :: (Int, Int) -> Int
{-# NOINLINE g #-}
g (p,q) = p+q

f :: Int -> Int -> Int -> Int
f x p q
  = g (let j y = (p,q)
           {-# NOINLINE j #-}
          in
          case x of
            2 -> j 3
            _ -> j 4)
      ==================== Strictness signatures ====================
Foo.$trModule: m
Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m



==================== Strictness signatures ====================
Foo.$trModule: m
Foo.f: <S(S),1*U(1*U)><S(S),1*U(U)><S(S),1*U(U)>m
Foo.g: <S(S(S)S(S)),1*U(1*U(U),1*U(U))>m
    • Alp Mestanogullari
      Alp Mestanogullari @alp ·
      Owner
      Trac metadata
      Trac field Value
      CC - → alpmestan
    • Ben Gamari added Pnormal label

      added Pnormal label

    Please register or sign in to reply