Newest at the top
| 2025-02-08 13:55:14 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
| 2025-02-08 13:54:56 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-02-08 13:53:38 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-02-08 13:49:25 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 13:31:57 +0100 | euleritian | (~euleritia@dynamic-176-006-128-136.176.6.pool.telefonica.de) (Ping timeout: 246 seconds) |
| 2025-02-08 13:28:36 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-08 13:21:56 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-08 13:18:41 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-02-08 13:18:26 +0100 | tavare | (~tavare@user/tavare) (Remote host closed the connection) |
| 2025-02-08 13:09:57 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f0539c4118aaa9fc29f.dip0.t-ipconnect.de) acidjnk |
| 2025-02-08 13:09:47 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2025-02-08 13:08:29 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Quit: Bye!) |
| 2025-02-08 13:06:51 +0100 | paddymahoney | (~paddymaho@pool-99-250-10-137.cpe.net.cable.rogers.com) (Quit: Leaving) |
| 2025-02-08 13:05:06 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
| 2025-02-08 13:02:14 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-02-08 13:00:59 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 13:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-02-08 12:53:59 +0100 | euleritian | (~euleritia@dynamic-176-006-128-136.176.6.pool.telefonica.de) |
| 2025-02-08 12:53:38 +0100 | euleritian | (~euleritia@ip4d17fae8.dynamic.kabel-deutschland.de) (Ping timeout: 252 seconds) |
| 2025-02-08 12:34:50 +0100 | dostoevsky | (~dostoevsk@user/dostoevsky) (Remote host closed the connection) |
| 2025-02-08 12:32:03 +0100 | tavare | (~tavare@user/tavare) tavare |
| 2025-02-08 12:31:33 +0100 | tavare | (~tavare@user/tavare) (Ping timeout: 252 seconds) |
| 2025-02-08 12:27:29 +0100 | emmanuelux | (~emmanuelu@user/emmanuelux) emmanuelux |
| 2025-02-08 12:17:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
| 2025-02-08 12:12:55 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-02-08 12:12:21 +0100 | hazmat_237 | (~hazmat_23@user/Monospace) (Ping timeout: 276 seconds) |
| 2025-02-08 12:09:39 +0100 | <euouae> | nice, thank you |
| 2025-02-08 12:09:22 +0100 | <geekosaur> | https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary is another very good place to look |
| 2025-02-08 12:08:49 +0100 | <geekosaur> | this happens post-Cmm in the compile pipeline |
| 2025-02-08 12:08:34 +0100 | acidjnk_new3 | (~acidjnk@p200300d6e7283f0588a4d7c575081360.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2025-02-08 12:08:17 +0100 | <euouae> | I'm realizing the GHC docs are a valuable source to learn stuff from |
| 2025-02-08 12:07:49 +0100 | <euouae> | very nice |
| 2025-02-08 12:07:41 +0100 | <geekosaur> | unless you're in LLVM mode where it outputs LLVM IR and calls `opt` and `llc` |
| 2025-02-08 12:07:24 +0100 | <geekosaur> | it generates assembly language and calls `as` on it |
| 2025-02-08 12:07:04 +0100 | <euouae> | yup; although it doesn't explain how the code is natively generated |
| 2025-02-08 12:06:27 +0100 | <geekosaur> | section 1.5.6 in particular, second entry |
| 2025-02-08 12:04:01 +0100 | <euouae> | ah thank you |
| 2025-02-08 12:03:51 +0100 | <int-e> | (more generally you can start from https://www.haskell.org/ghc/download.html and select the version and that'll have a release notes link) |
| 2025-02-08 12:03:23 +0100 | <int-e> | https://downloads.haskell.org/~ghc/7.2.1/docs/html/users_guide/release-7-2-1.html |
| 2025-02-08 12:02:40 +0100 | <euouae> | I can't find a changelog file, how can I read the GHC notes for 7.2? |
| 2025-02-08 12:02:24 +0100 | <euouae> | no that's not what I meant |
| 2025-02-08 12:00:58 +0100 | <geekosaur> | unless you mean unregisterised mode, but you absolutely don't want that if you want speed; it's intended for porting and produces extremely slow but extremely portable ANSI C |
| 2025-02-08 11:59:56 +0100 | <geekosaur> | not since 7.2 |
| 2025-02-08 11:59:28 +0100 | <euouae> | does ghc still target C? because tahts' what STG targets in SPJs paper |
| 2025-02-08 11:53:47 +0100 | <geekosaur> | (certainly old implementation papers will be too old to help, especially since none of them will know about amd64 or aarch64) |
| 2025-02-08 11:48:28 +0100 | <geekosaur> | there are a few things at Cmm and STG levels but you won't find anything except the ghc source to help with those |
| 2025-02-08 11:48:19 +0100 | <euouae> | Ah, hm... I meant that I want to write code that is fast, not to study the optimizations of GHC |
| 2025-02-08 11:47:50 +0100 | <geekosaur> | almost all optimizations in ghc are done at the level of Core |
| 2025-02-08 11:47:46 +0100 | <euouae> | I've read that Core does not capture certain issues with memory use & other benchmarking analysis |
| 2025-02-08 11:47:25 +0100 | <geekosaur> | GRIN itself seems to be kinda stuck, but STGi will show you how STG works without requiring you to delve into implementation details (SPJ's paper talks a lot about register allocation etc.) |