Opened 10 years ago

Closed 4 years ago

#1547 closed bug (wontfix)

Arity can decrease with -prof

Reported by: igloo Owned by:
Priority: normal Milestone:
Component: Profiling Version: 6.6.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: stm package/tests/conc052
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by simonpj)

Something like

  f = \p\q.body
  x = scc "foo" f (\y.e)

shows f having arity 2, and hence x having arity 1. But when we inline f, we get

  x = scc "foo" let p = \x.e in \q.body

and the cheap-and-cheerful arity discovery function (exprArity) detects arity of 0, not 1. And then CoreLint complains about the inconsistency of arity and strictness info.

This is unpleasant but not actually a problem.

It shows up in the conc052 test (in the stm package).

Part of #1546 might be the same problem.

Change History (8)

comment:1 Changed 9 years ago by simonpj

Description: modified (diff)
Milestone: 6.8 branch6.10 branch
Summary: conc052 core lint errors in profc/profasm waysArity can decrease with -prof
Test Case: stm package/tests/conc052

comment:2 Changed 9 years ago by simonpj

I had a half-done change in SimplUtils which I'm just going to dump here for now. The actual code change (which I am not sure is right) is this:

hunk ./compiler/simplCore/SimplUtils.lhs 827
-   	any isRuntimeVar bndrs
+   	any isRuntimeVar bndrs || not (exprIsTrivial body)
+		-- Note [RHS eta expansion]

and the note is this:

Note [RHS eta expansion]
The basic idea is to transform
   f = \x1..xn -> N  ==>   f = \x1..xn y1..ym -> N y1..ym
				 (n >= 0)
where (in both cases) 

	* The xi can include type variables

	* The yi are all value variables

	* N is a NORMAL FORM (i.e. no redexes anywhere)
	  wanting a suitable number of extra args.

This is OK even if n=0; for example: 
	let g=\xs. x:xs in (\ys. map g ys)
Here we can eta expand to
	\ys. let g=\xs. x:xs in map g ys
You might think the f-binding woudl have floated, but it may not when
we are profiling:
	f = scc "foo" (let g=\xs. x:xs in (\xs. map g ys))
Furthermore, f's arity might have been 1 before, if it originally looked
	h g ys = map g ys
	f = scc "foo" (h (\xs. x:xs))
and we do not expect like the arity to decrease so that it now looks 
like zero (to the cheap-and-cheerful exprArity).

However, we must be careful not to undo the effect of eta-reduction, hence
the check for `(not (exprIsTrivial body))`.

I just want to capture the state of play because I can't finish this today.


comment:3 Changed 9 years ago by simonmar

Update: conc052 is now apparently not failing any more, but this bug hasn't been fixed. I imagine something else has changed such that we don't tickle the bug any more.

comment:4 Changed 9 years ago by simonmar

Milestone: 6.10 branch_|_
Priority: highnormal

bug isn't manifesting any more, and doesn't seem to be an urgent problem.

comment:5 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:6 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:7 Changed 4 years ago by morabbin

Type of failure: None/Unknown

Bump; close as fixed?

comment:8 Changed 4 years ago by simonmar

Resolution: wontfix
Status: newclosed

We know there are several problems with the current way that arity is calculated too early, and we plan to refactor things so that arity is calculated after CorePrep instead, which would fix this bug.

Hence I don't think there's much to be gained by keeping the ticket open. It's unlikely we'll want to fix this bug in isolation.

Note: See TracTickets for help on using tickets.