March 2017 - ghc-tickets

[GHC] #12699: Suspicious treatment of renaming of field labels
by GHC 01 Mar '17

01 Mar '17

#12699: Suspicious treatment of renaming of field labels -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on my rework of interface file names (Phab:D2467) I noticed that there is some funniness in the treatment of renaming field selectors. Namely, `ifaceConDeclFields` are `IfaceTopBndr`s (and should therefore be renamed), renaming them causes `bkpreex06` to fail with the panic `find_lbl missing foo`. Looking at the environment reveals that there are selectors named `foo` in scope, but they were not renamed. I believe this is due to the implementation of `tcIfaceDataCons`, which typechecks the fields with `mapM (traverse lookupIfaceTop) (ifaceConDeclFields if_cons)`. In essence, this projects the field labels back to `OccName`s (in `ifaceConDeclFields`) and then looks each of these `OccName`s up in the name cache, thereby retrieving the un-renamed `Name`. This seems wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13286: Late floating of join points
by GHC 01 Mar '17

01 Mar '17

#13286: Late floating of join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this, from `GHC.Real`: {{{ GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> joinrec { $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# [LclId[JoinId(2)], Arity=2, Str=<S,U><S,U>, Unf=OtherCon []] $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> joinrec { $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# [LclId[JoinId(3)], Arity=3, Str=<S,U><S,U><S,U>, Unf=OtherCon []] $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 }; } in jump $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> jump $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) }; } in jump $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Note those two `joinrecs`. Neither has any free variables. So we could float them to top level, as ordinary functions, thus {{{ $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} Is this better? * Better before: the nested join points don't allocate a closure; but the top-level defns do build a (never used) closure and slow entry point. * Better after: the externally-visible function might inline more at call sites in other modules. So it's a bit moot. It has something of the flavour of the late lambda- lifting pass. For now I'm doing nothing; just recording the observation. The simple thing is not to float. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13236: Improve floating for join points
by GHC 01 Mar '17

01 Mar '17

#13236: Improve floating for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having looked at the code in `SetLevels`, am very uncomfortable. My nose tells me that there is far too much chuffing about; it all makes my head spin. '''Question 1'''. Why do we ever "ruin" a join point? See {{{ Note [When to ruin a join point] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generally, we protect join points zealously. However, there are two situations in which it can pay to promote a join point to a function: 1. If the join point has no value arguments, then floating it outward will make it a *thunk*, not a function, so we might get increased sharing. 2. If we float the join point all the way to the top level, it still won't be allocated, so the cost is much less. Refusing to lose a join point in either of these cases can be disastrous ---for instance, allocation in imaginary/x2n1 *triples* because $w$s^ becomes too big to inline, which prevents Float In from making a particular binding strictly demanded. }}} But I don't agree at all. If we have {{{ let-join j = e in b }}} then we can leave `j` in place as a join point. We can float `e` (via `lvlMFE`) if doing so would increase sharing. Indeed this applies uniformly to all join points. For example {{{ f x = let g y = let-join j z1 z2 = expensive x in case y of A p q -> j p q B r -> j r r C -> True }}} Here it would make sense to float `(expensive x)` out of the `\y` abstrction: {{{ f x = let lvl = expensive x g y = let-join j z1 z2 = lvl in case y of A p q -> j p q B r -> j r r C -> True }}} But doing so does not affect the join point `j`. Nullary join points are no different. This includes floating to the top level. Incidentally the RHS of the join point then becomes tiny, so the join point will be inlined. In short, I think we can just delete all this special code. '''Question 2''': `Note [Join points and MFEs]`. Whe do we ''ever'' float out a MFE that has a free join variable? SLPJ claim: if there is a free join variable, do not float it anywhere. '''Question 3''': Do we actually need to float join points ''at all''? Why? I thik the reason is just to make them small {{{ let-join j1 x = let-join j2 y = y+1 in ... }}} Here perhaps if we float `j2` out of `j1` that might make `j1` small enough to inline. But if that is the only motivation (unlike most of `FloatOut` which is about saving work) we'd better say so loud and clear. And the question is a bit more complicated; e.g. we might want to abstract over Ids to achieve this. e.g. {{{ let-join j1 x = let-join j2 y = x+y in ... ===> let-join j2' x y = x+y j1 x = let-join j2 y = j2' x y in ... }}} Now we can inline `j2`. (The example would be more realistic if the `x+y` was a big expression.) It's not just join parameters; we can abstract over any free variables: {{{ let-join j1 x = let p = x+y in let-join j2 z = p+z in .... }}} Here we could abstract `j2` over `p` in order to float it. It is not clear how best to do this; but I worry that we are asking `FloatOut` to do too much. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13236> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13355: gmp doesn't build correctly when cross-compiling with clang
by GHC 01 Mar '17

01 Mar '17

#13355: gmp doesn't build correctly when cross-compiling with clang -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The commit in #8497 added this to `libraries/integer-gmp/gmp/ghc.mk`: {{{ CLANG = $(findstring clang, $(shell $(CC_STAGE1) --version)) ifeq "$(CLANG)" "clang" CCX = $(CLANG) else CCX = $(CC_STAGE1) endif }}} and does the build with `$(CCX)` rather than `$(CC_STAGE1)`. However, when cross-compiling, `$(CC_STAGE1)` could be a clang cross- compiler, but then it's certainly not right to use `$(CLANG) = clang`, as that is presumably not a cross-compiler. I don't understand why the issue in #8497 arose in the first place, so it's unclear to me how to proceed here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0