#15001 closed task (wontfix)

Add strict product field demands to lambda binders

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


This is a follow-up on the first improvement in D4244#126311.

Consider the following two functions with identical semantics:

module Foo where

{-# LANGUAGE BangPatterns #-}
data Complex a = !a :+ !a

foo :: Complex Double -> Int -> Complex Double
foo !x 0 = x
foo (a :+ b) _ = b :+ a

bar :: Complex Double -> Int -> Complex Double
bar x 0 = x
bar (a :+ b) _ = b :+ a

In the corresponding simplified Core, x gets strictness S(SS) for foo, but only S for bar. We could do better by looking at xs type and see that its a product type with strict fields.

This is because currently only case binders get special treatment for strict product fields through addDataConStrictness.

This ticket tracks if the same is worthwhile for lambda binders, as in bar above. Note that intuitively, this shouldn't make any difference because when we eventually unleash an S demand on a Complex constructor, we add seqDmd on strict fields anyway, amounting to S(SS). So this is only a matter of recording things early because some parts of the analysis code might not be smart enough to add strict field demands by themselves.

Also note that this doesn't touch impliciations on usage analysis at all, where unleashing the same seqDmd twice might mean we accidentally make some product field lose its single-entrieness.

Attachments (1)

nofib-table-all.txt (195.8 KB) - added by sgraf 19 months ago.
Results from NoFib run

Download all attachments as: .zip

Change History (5)

comment:1 Changed 19 months ago by sgraf

Differential Rev(s): D4244D4244 D4563

Changed 19 months ago by sgraf

Attachment: nofib-table-all.txt added

Results from NoFib run

comment:2 Changed 19 months ago by sgraf

No changes to allocation, and +-0% on counted instructions. So, basically no change at all. Question is, do the prettier and more consistent results warrant the complexity? I'd say no, at least until there's a compelling reason we need this (as part of nested CPR).

comment:3 Changed 19 months ago by simonpj

I agree -- not worth it.

comment:4 Changed 19 months ago by sgraf

Differential Rev(s): D4244 D4563[Phab:D4244] [Phab:D4563]
Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.