Opened 9 years ago

Last modified 13 months ago

#1885 new feature request

Improve CPR analysis

Reported by: simonpj Owned by:
Priority: lowest Milestone:
Component: Compiler Version: 6.8.1
Keywords: Cc: mail@…
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 (last modified by simonpj)

When a function returns a nested data structure, GHC should expose that fact to the caller. This can make a very big difference in inner loops. A good example is the following message (from GHC users http://www.haskell.org/pipermail/glasgow-haskell-users/2007-November/013454.html).

Compile the attached files thus:

ghc --make Unpacked.hs -O2 -cpp -DPOLY_SAME

and similarly with DPOLY_OTHER. The POLY_OTHER case does a lot more allocation because a key function isn't inlined.

$wa_r1Wb :: GHC.Prim.Addr#
	    -> GHC.Prim.State# GHC.Prim.RealWorld
	    -> (# GHC.Prim.State# GHC.Prim.RealWorld,
		  OtherP.C
		    GHC.Float.Double (OtherP.C GHC.Float.Double 
                                         (OtherP.C GHC.Float.Double ())) #)
[GlobalId]
[Arity 2
 NoCafRefs
 Str: DmdType LL]
$wa_r1Wb =
  \ (ww_s1S5 :: GHC.Prim.Addr#) (w_s1S7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
    case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ww_s1S5 0 w_s1S7
    of wild2_a1xI { (# s2_a1xK, x_a1xL #) ->
    let {
      ipv_XGd [Just L] :: GHC.Prim.Addr#
      [Str: DmdType]
      ipv_XGd = GHC.Prim.plusAddr# ww_s1S5 8 } in
    case GHC.Prim.readDoubleOffAddr# @ GHC.Prim.RealWorld ipv_XGd 0 s2_a1xK
    of wild21_X1yK { (# s21_X1yN, x1_X1yP #) ->
    case GHC.Prim.readDoubleOffAddr#
	   @ GHC.Prim.RealWorld (GHC.Prim.plusAddr# ipv_XGd 8) 0 s21_X1yN
    of wild22_X1yU { (# s22_X1yX, x2_X1yZ #) ->
    (# s22_X1yX,
       OtherP.C
	 @ GHC.Float.Double
	 @ (OtherP.C GHC.Float.Double (OtherP.C GHC.Float.Double ()))
	 (GHC.Float.D# x_a1xL)
	 (OtherP.C
	    @ GHC.Float.Double
	    @ (OtherP.C GHC.Float.Double ())
	    (GHC.Float.D# x1_X1yP)
	    (OtherP.C @ GHC.Float.Double @ () 
                    (GHC.Float.D# x2_X1yZ) GHC.Base.())) #)
    } } }

Attachments (3)

OtherM.hs (858 bytes) - added by simonpj 9 years ago.
OtherP.hs (1.4 KB) - added by simonpj 9 years ago.
Unpacked.hs (3.1 KB) - added by simonpj 9 years ago.

Download all attachments as: .zip

Change History (23)

Changed 9 years ago by simonpj

Attachment: OtherM.hs added

Changed 9 years ago by simonpj

Attachment: OtherP.hs added

Changed 9 years ago by simonpj

Attachment: Unpacked.hs added

comment:1 Changed 9 years ago by simonpj

Description: modified (diff)

comment:2 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:3 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:4 Changed 8 years ago by igloo

Milestone: 6.10 branch6.12 branch

comment:5 Changed 7 years ago by igloo

Milestone: 6.12 branch6.12.3

comment:6 Changed 7 years ago by igloo

Milestone: 6.12.36.14.1
Priority: normallow

comment:7 Changed 6 years ago by igloo

Milestone: 7.0.17.0.2

comment:8 Changed 6 years ago by igloo

Milestone: 7.0.27.2.1

comment:9 Changed 5 years ago by igloo

Milestone: 7.2.17.4.1

comment:10 Changed 5 years ago by igloo

Milestone: 7.4.17.6.1
Priority: lowlowest

comment:11 Changed 4 years ago by igloo

Milestone: 7.6.17.6.2

comment:12 Changed 4 years ago by morabbin

Type: taskfeature request
Type of failure: None/Unknown

See also #2289 and #1600.

comment:13 Changed 3 years ago by nomeata

Cc: mail@… added

comment:14 Changed 3 years ago by nomeata

Resolution: fixed
Status: newclosed

Just tested this with GHC 7.6.3, and with -DPOLY_OTHER it runs really fast. So I guess this can be closed (and looks like it is not related to nested CPR).

comment:15 Changed 3 years ago by simonpj

Owner: simonpj deleted
Resolution: fixed
Status: closednew

Well, it would be good to know WHY it runs really fast. Maybe the function is being inlined... but it it was bigger it wouldn't be, and nested CPR might be just the job. I'd rather know that it was fixed (rather than just have the symptoms disappear) before closing the ticket.

comment:16 Changed 3 years ago by thoughtpolice

Milestone: 7.6.27.10.1

Moving to 7.10.1.

comment:17 Changed 2 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:18 Changed 2 years ago by thoughtpolice

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:19 Changed 18 months ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:20 Changed 13 months ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.