: ÉRDI Gergő
| Sent: 12 March 2021 11:23
| To: Simon Peyton Jones
| Cc: GHC Devs
| Subject: RE: Inlining of `any @[]` vs `elem @[]`
|
| On Fri, 12 Mar 2021, Simon Peyton Jones wrote:
|
| > I'm not sure... you could investigate, but I'm inclined just to
| declare victory!
On Fri, 12 Mar 2021, Simon Peyton Jones wrote:
I'm not sure... you could investigate, but I'm inclined just to declare victory!
That's easy for you to say, but here I am stuck with Stack not supporting
GHC 9.0... https://github.com/commercialhaskell/stack/issues/5486
To: Simon Peyton Jones
| Cc: GHC Devs
| Subject: RE: Inlining of `any @[]` vs `elem @[]`
|
| On Thu, 11 Mar 2021, Simon Peyton Jones wrote:
|
| > With HEAD, and -O, I get the exact same (good code) for these two
| functions:
| >
| >f x = any (x ==) [1, 5, 7::Int]
| >
|
On Fri, 12 Mar 2021, ÉRDI Gergő wrote:
I wonder why that is? What changed between GHC 8.10.3 and 9.0.1? Was the
definition of `elem` changed in `base`?
Oh, I've found this commit:
```
commit f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495
Author: Andreas Klebinger
Date: Wed Jan 29 15:25:07 2020 +
On Thu, 11 Mar 2021, Simon Peyton Jones wrote:
With HEAD, and -O, I get the exact same (good code) for these two functions:
f x = any (x ==) [1, 5, 7::Int]
g x = elem x [2, 6, 9 :: Int]
Maybe this is fixed? If you think not, maybe open a ticket?
OK, so initially I tried it
> GHC.Types.True;
6# -> GHC.Types.True;
9# -> GHC.Types.True
}
}
Maybe this is fixed? If you think not, maybe open a ticket?
Simon
| -Original Message-
| From: ghc-devs On Behalf Of ÉRDI Gergo
| Sent: 07 March 2021 02:59
| To: GHC Devs
| Subject: Inlining
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 go
