Newest at the top
| 2026-02-15 00:03:16 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 23:56:09 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2026-02-14 23:53:36 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 252 seconds) |
| 2026-02-14 23:51:08 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-14 23:50:02 +0100 | oskarw | (~user@user/oskarw) (Ping timeout: 252 seconds) |
| 2026-02-14 23:46:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 23:38:48 +0100 | housemate | (~housemate@202.7.248.67) housemate |
| 2026-02-14 23:32:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2026-02-14 23:30:55 +0100 | housemate | (~housemate@202.7.248.67) (Quit: https://ineedsomeacidtocalmmedown.space/) |
| 2026-02-14 23:27:20 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 23:27:11 +0100 | caubert | (~caubert@user/caubert) caubert |
| 2026-02-14 23:16:09 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-14 23:12:19 +0100 | poscat | (~poscat@user/poscat) (Ping timeout: 250 seconds) |
| 2026-02-14 23:11:29 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 23:10:49 +0100 | poscat0x04 | (~poscat@user/poscat) poscat |
| 2026-02-14 23:08:50 +0100 | haritz | (~hrtz@user/haritz) haritz |
| 2026-02-14 23:08:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) (Changing host) |
| 2026-02-14 23:08:50 +0100 | haritz | (~hrtz@2a01:4b00:bc2e:7000:d5af:a266:ca31:5ef8) |
| 2026-02-14 23:08:42 +0100 | wickedjargon | (~user@24.83.46.194) wickedjargon |
| 2026-02-14 23:05:52 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) |
| 2026-02-14 23:04:49 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-02-14 22:59:59 +0100 | caubert | (~caubert@user/caubert) (Ping timeout: 252 seconds) |
| 2026-02-14 22:59:52 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 22:56:09 +0100 | acidjnk | (~acidjnk@p200300d6e700e5606490ca8182989074.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
| 2026-02-14 22:54:34 +0100 | caubert | (~caubert@user/caubert) caubert |
| 2026-02-14 22:48:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-14 22:43:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 22:42:43 +0100 | <tomsmeding> | 99% certain they don't built on top of vector and allocate their own primitive arrays |
| 2026-02-14 22:40:56 +0100 | <[exa]> | probie: btw really try if repa manages to SIMD, deconstructing a working instance is a MUCH easier way to debug compilers than trying to hit a subtle trick that does it |
| 2026-02-14 22:40:50 +0100 | <int-e> | *led |
| 2026-02-14 22:40:44 +0100 | caubert | (~caubert@user/caubert) (Ping timeout: 245 seconds) |
| 2026-02-14 22:40:41 +0100 | <int-e> | It lead to `inlinePerformIO` being renamed :-) |
| 2026-02-14 22:40:12 +0100 | <int-e> | probie: Well, you have mutable data there; even lazy evaluation shouldn't accidentally alias those. (Though for people who remember the early days of bytestring... yes, these things have happened.) |
| 2026-02-14 22:39:05 +0100 | <tomsmeding> | it might be possible to devise something in combination with linear types |
| 2026-02-14 22:38:36 +0100 | <probie> | We need a new GHC extension that introduces the `restrict` keyword (although I can't imagine that being a sane thing to have in the context of non-strict evaluation) |
| 2026-02-14 22:38:03 +0100 | <int-e> | and it'll get awkward regardless if the relative alignment of the two pointers isn't 0. |
| 2026-02-14 22:37:24 +0100 | <[exa]> | oh yes true |
| 2026-02-14 22:37:11 +0100 | <tomsmeding> | [exa]: remember this is a loop with dependencies so llvm can't unroll |
| 2026-02-14 22:37:01 +0100 | <int-e> | And I don't think you can express the promise that these two pointers never alias at the Haskell level. |
| 2026-02-14 22:36:54 +0100 | <[exa]> | is it? (does the vector start on aligned addr?) |
| 2026-02-14 22:36:17 +0100 | <tomsmeding> | ah yes, in this case it is |
| 2026-02-14 22:36:01 +0100 | <int-e> | tomsmeding: well, the alignment is already fixed by how you unrolled the loop |
| 2026-02-14 22:36:00 +0100 | <[exa]> | like, ofc llvm is going to brainify that to The Way Better Aligned Load |
| 2026-02-14 22:35:40 +0100 | <tomsmeding> | I'm... not sure what I was thinking |
| 2026-02-14 22:35:33 +0100 | <tomsmeding> | [exa]: good point, my bad, yes loadu is a thing |
| 2026-02-14 22:35:07 +0100 | <tomsmeding> | so it should just generate a prologue |
| 2026-02-14 22:34:58 +0100 | <tomsmeding> | but yes, I guess that llvm will have to deal with unaligned arrays anyway because it cannot assume any arbitrary pointer is aligned |
| 2026-02-14 22:34:47 +0100 | <[exa]> | loadu doesn't exist for epi8? |
| 2026-02-14 22:34:23 +0100 | <tomsmeding> | [exa]: simd instructions do have alignment constraints where normal x86 memory ops don't |
| 2026-02-14 22:33:48 +0100 | <[exa]> | probie: the alignment isn't a totally huge deal (just adds a bit of a weight on whether llvm later chooses the unaligned load or doesn't even trigger) |