Re: What changed between GHC 8.8 and 8.10 that could cause this?
Thanks Matthew and Julian! Unfortunately, trying out GHC before/after this change didn't turn out to be as easy as I hoped: to do my testing, I need to build a given GHC commit, and then use that via Stack to install ~140 dependencies so that I can then test the problem I have initially seen. And it turns out doing that with a random GHC commit is quite painful because in any given Stackage snapshot there will be packages with which the GHC-bundled libraries are incompatible... :/ On Thu, 4 Mar 2021, Julian Leviston wrote: Hi,I don’t know enough about what Clash does to comment really, but it sounds like it’s to do with my work on enabling multiple linker instances in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388 — maybe reading through that or the plan I outlined at https://gitlab.haskell.org/ghc/ghc/-/issues/3372 might help, though I’m not sure. Strange, though, as this work was to isolate state in GHC — to change it from using a global IORef to use a per-process MVar . But it definitely did change the way state is handled, so it might be the related to these issues somehow? I realise this isn’t much help, but maybe it points you in a direction where you can begin to understand some more. Julian On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő wrote: Hi, I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation. The details are at https://github.com/clash-lang/clash-compiler/issues/1686 but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process. So, does this ring a bell for anyone? Thanks, Gergo ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- .--= ULLA! =-. \ http://gergo.erdi.hu \ `---= ge...@erdi.hu =---' I tried to commit suicide once by taking over 1,000 aspirin. But after I took 2, I felt better!___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Inlining of `any @[]` vs `elem @[]`
Hi,
The inlining behaviour of `any @[]` and `elem @[]` differs in a way that I
am not sure is intentional, and it is affecting Clash (see
https://github.com/clash-lang/clash-compiler/issues/1691). I would think
that if it is a good idea to inline `any` then inlining `elem` would be
just as good an idea, or vice versa.
However, `any` is defined polymorphically over `Foldable`, via `foldMap`
using `foldr`, with all steps between (and `foldr @[]`!) marked as
`INLINE`. The result is that if you use `any (x ==) [1, 5, 7]` you get the
following beautiful Core:
```
topEntity
= \ (x_agAF :: Int) ->
case x_agAF of { GHC.Types.I# y_ahao ->
case y_ahao of {
__DEFAULT -> GHC.Types.False;
1# -> GHC.Types.True;
5# -> GHC.Types.True;
7# -> GHC.Types.True
}
}
```
As the kids these days would say: *chef's kiss*.
`elem`, on the other hand, is a typeclass method of `Foldable`, with a
default implementation in terms of `any`, but overridden for lists with the
following implementation:
```
GHC.List.elem :: (Eq a) => a -> [a] -> Bool
GHC.List.elem _ [] = False
GHC.List.elem x (y:ys) = x==y || GHC.List.elem x ys
{-# NOINLINE [1] elem #-}
{-# RULES
"elem/build"forall x (g :: forall b . Eq a => (a -> b -> b) -> b -> b)
. elem x (build g) = g (\ y r -> (x == y) || r) False
#-}
```
This is marked as non-inlineable until phase 1 (so that `elem/build` has a
chance of firing), but it seems that when build fusion doesn't apply
(since `[1, 5, 7]` is, of course, not built via `build`), no inlining
happens AT ALL, even in later phases, so we end up with this:
```
topEntity
= \ (x_agAF :: Int) ->
GHC.List.elem
@ Int
GHC.Classes.$fEqInt
x_agAF
(GHC.Types.:
@ Int
(GHC.Types.I# 1#)
(GHC.Types.:
@ Int
(GHC.Types.I# 5#)
(GHC.Types.: @ Int (GHC.Types.I# 7#) (GHC.Types.[] @ Int
```
So not only does it trip up Clash, it would also result in less efficient
code in software when using "normal" GHC.
Is this all intentional? Wouldn't it make more sense to mark
`GHC.List.elem` as `INLINE [1]` instead of `NOINLINE [1]`, so that any
calls remaining after build fusion would be inlined?
Thanks,
Gergo
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Exactprint merge process
"Alan & Kim Zimmerman" writes: > I have been running a branch in !2418[1] for just over a year to migrate > the ghc-exactprint functionality directly into the GHC AST[2], and I am now > satisfied that it is able to provide all the same functionality as the > original. > > This is one of the features intended for the impending 9.2.1 release, and > it needs to be reviewed to be able to land. But the change is huge, as it > mechanically affects most files that interact with the GHC AST. > > So I have split out a precursor !5158 [3] with just the new types that are > used to represent the annotations, so it can be a focal point for > discussion. > > It is ready for review, please comment if you have time and interest. > Thanks Alan! I'll have a look. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
GHC Exactprint merge process
I have been running a branch in !2418[1] for just over a year to migrate the ghc-exactprint functionality directly into the GHC AST[2], and I am now satisfied that it is able to provide all the same functionality as the original. This is one of the features intended for the impending 9.2.1 release, and it needs to be reviewed to be able to land. But the change is huge, as it mechanically affects most files that interact with the GHC AST. So I have split out a precursor !5158 [3] with just the new types that are used to represent the annotations, so it can be a focal point for discussion. It is ready for review, please comment if you have time and interest. Regards Alan [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418 [2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638 [3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
