Newest at the top
| 2026-02-14 21:34:44 +0100 | <tomsmeding> | possibly, yes |
| 2026-02-14 21:33:37 +0100 | peterbecich | (~Thunderbi@71.84.33.135) (Ping timeout: 264 seconds) |
| 2026-02-14 21:32:46 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 21:29:31 +0100 | pavonia | (~user@user/siracusa) siracusa |
| 2026-02-14 21:29:02 +0100 | <probie> | I wonder if it's the use of `read` instead of `unsafeRead`? |
| 2026-02-14 21:28:52 +0100 | <probie> | It's not giving me SIMD instruction :'( |
| 2026-02-14 21:26:38 +0100 | ouilemur | (~jgmerritt@user/ouilemur) ouilemur |
| 2026-02-14 21:25:54 +0100 | <geekosaur> | also I mentioned the settings file bvecause I saw a claim in backscroll that the correct llvm version wasn't on their PATH, which means a settings file edit to point to the correct one |
| 2026-02-14 21:23:31 +0100 | <geekosaur> | there was a point where `opt` parameters changed and ghc didn't know how tgo call newer versions correctly |
| 2026-02-14 21:23:07 +0100 | <geekosaur> | they can be pretty critical but I don't think it's critical for recent versions |
| 2026-02-14 21:22:08 +0100 | <int-e> | Hmm. For me, the baked in commands (from the settings file) have a version, e.g. llc-14 for ghc-9.10.3 and llc-19 for ghc-9.12.2. I wonder what the binary distributions put there... ghc --info | grep LLVM will show that info without you having to go looking for the settings file. |
| 2026-02-14 21:21:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 250 seconds) |
| 2026-02-14 21:18:38 +0100 | <int-e> | I don't |
| 2026-02-14 21:18:17 +0100 | <tomsmeding> | do you happen to know how critical those version upper bounds are, in GHC's LLVM support? |
| 2026-02-14 21:18:07 +0100 | s3np41 | (~s3np41@078088254000.unknown.vectranet.pl) |
| 2026-02-14 21:17:56 +0100 | <int-e> | (Rather than digging into the history I'll just assume this hasn't changed recently except for bumping versions.) |
| 2026-02-14 21:17:44 +0100 | <tomsmeding> | I see |
| 2026-02-14 21:16:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 21:16:26 +0100 | <int-e> | tomsmeding: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/SysTools/Tasks.hs#L341-350 (and beyond) |
| 2026-02-14 21:15:32 +0100 | <geekosaur> | "LLVM opt command" (and similar for llc) |
| 2026-02-14 21:15:14 +0100 | <geekosaur> | $(ghc --print-libdir)/settings |
| 2026-02-14 21:15:13 +0100 | caubert | (~caubert@user/caubert) caubert |
| 2026-02-14 21:14:58 +0100 | <geekosaur> | I think you can specify a path in the settings file? |
| 2026-02-14 21:14:18 +0100 | <tomsmeding> | lame |
| 2026-02-14 21:14:11 +0100 | <int-e> | tomsmeding: AFAICS it tries llc -version (or whatever -pgmlc is) |
| 2026-02-14 21:13:04 +0100 | <tomsmeding> | this seems to be the compatibility matrix https://paste.tomsmeding.com/NJhIVIyh |
| 2026-02-14 21:12:11 +0100 | caubert | (~caubert@user/caubert) (Ping timeout: 252 seconds) |
| 2026-02-14 21:11:14 +0100 | <tomsmeding> | apart from just calling `opt`, that is |
| 2026-02-14 21:11:04 +0100 | <tomsmeding> | int-e: https://play.haskell.org/saved/yNy86HlS this output suggest it does _something_ |
| 2026-02-14 21:10:26 +0100 | <int-e> | (And I see no indication that it can interrogate llvm-config) |
| 2026-02-14 21:09:53 +0100 | <int-e> | There are half a dozen -pgm* flags for the various llvm tools ghc might use. -pgmlo is for `opt`. |
| 2026-02-14 21:07:44 +0100 | <probie> | It's good to know I'm not the only one to have that idea |
| 2026-02-14 21:06:54 +0100 | <tomsmeding> | probie: https://git.tomsmeding.com/pathenv/tree/pathenv ? |
| 2026-02-14 21:06:21 +0100 | <probie> | the problem is that the `opt` there is the wrong version. I'm just going to brute force my way through and make symlinks to the right ones in a folder and the stick that folder on my path |
| 2026-02-14 21:06:09 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2026-02-14 21:05:45 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
| 2026-02-14 21:05:35 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-14 21:05:16 +0100 | <tomsmeding> | generally one tells programs of LLVM by ensuring its llvm-config executable is in $PATH |
| 2026-02-14 21:05:06 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
| 2026-02-14 21:05:01 +0100 | <tomsmeding> | though perhaps it looks for llvm-config first |
| 2026-02-14 21:04:52 +0100 | <tomsmeding> | it seems it will just look for `opt` in $PATH |
| 2026-02-14 21:04:33 +0100 | <probie> | now how do I tell GHC where my llvm is... |
| 2026-02-14 21:00:47 +0100 | <int-e> | `vector` makes at least one SIMD-unfriendly design choice though: `drop` is O(1) so there's no alignment guaranteee beyond the primitive data type for unboxed vectors. |
| 2026-02-14 21:00:37 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 21:00:09 +0100 | <int-e> | Hmm, https://minoki.github.io/posts/2025-01-13-ghc-simd.html looks like a decent overview of the state of the SIMD primitives in GHC? |
| 2026-02-14 20:58:30 +0100 | <tomsmeding> | no that's not quite right |
| 2026-02-14 20:57:35 +0100 | <tomsmeding> | and 13-17 for 9.10 and higher |
| 2026-02-14 20:56:56 +0100 | <tomsmeding> | seems LLVM 12 will do for 9.0 up to and including 9.8 |
| 2026-02-14 20:55:11 +0100 | <int-e> | subtle |
| 2026-02-14 20:53:27 +0100 | <tomsmeding> | I wonder if the maintainer of the playground could be bribed to make -fllvm work there. |