Opened 3 years ago

Closed 3 years ago

Last modified 21 months ago

#13543 closed bug (fixed)

Improve demand analysis for join points

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: JoinPoints Cc: alpmestan
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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!

Change History (7)

comment:1 Changed 3 years ago by simonpj

Keywords: JoinPoints added

comment:2 Changed 3 years ago by Simon Peyton Jones <simonpj@…>

In b5b7d82/ghc:

Improve demand analysis for join points

I realised (Trac #13543) that we can improve demand analysis for
join point quite straightforwardly.

The idea is explained in
    Note [Demand analysis for join points]
in DmdAnal

comment:3 Changed 3 years ago by simonpj

Resolution: fixed
Status: newclosed

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

comment:4 Changed 21 months ago by alpmestan

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?

comment:5 Changed 21 months ago by bgamari

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.

comment:6 Changed 21 months ago by alpmestan

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

comment:7 Changed 21 months ago by alpmestan

Cc: alpmestan added
Note: See TracTickets for help on using tickets.