Another arity expansion bug

Roman reports: I've finally tracked down one big optimisation problem (at least, I think it is big). Here is a small example:

foo :: Eq a => a -> a
{-# NOINLINE foo #-}
foo x = x

bar :: Eq a => a -> a
{-# INLINE [1] bar #-}
bar x = let p = foo (x,x)
             q = foo (p,p) in fst (fst q)

For some reason, bar's arity is 1 which is wrong. If we replace (fst (fst q)) by (fst p), it gets the correct arity of 2.

The problem is that because of the arity, (bar $dEq) is then floated out as far as possible which breaks fusion if we have RULES for bar. In case you are interested, this affects splitSD in dph-prim-par/Data/ Array/Parallel/Unlifted/Distributed/Arrays.hs. I haven't noticed this previously because we didn't use segmented arrays as much.

Trac metadata

Trac field	Value
Version	6.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture