| 6 Sep 2025 |
emily | er not intersection exactly. you know what i mean :) | 18:15:20 |
sterni | LLVM backend could be totally unusable already now and we wouldn't really know unfortunately. | 18:22:29 |
sterni | technically, this fix would help LLVM 19 compat insofar as it helps LLVM >= 3.4.0 compat :D https://gitlab.haskell.org/ghc/ghc/-/issues/25019 | 18:26:12 |
emily | well, it works enough on 9.4 with my patches to build GHC itself at least… | 18:29:30 |
emily | but yeah I don't get the impression there is much care for it | 18:29:53 |
emily | even the LoongArch64 person making an mcmodel fix was like "this isn't a good fix because we should just have NCG" | 18:30:03 |
sterni | true, but we don't really exercise it with later versions of GHC I think | 18:30:04 |
emily | I did my best, though, in terms of backporting everything LLVM-version-relevant | 18:30:30 |
emily | pretty sure I was more thorough than upstream is when bumping from what i saw | 18:30:52 |
sterni | yes, I did not find anything you missed; except for a fix for llvm-ar >= 17, but that's unrelated to the llvmPackages we take as an input | 18:35:04 |
sterni | I think worrying about hostPlatform.useLLVM is for some other time | 18:35:24 |
emily | hm would that not be picked up from the wrapping we do? | 18:37:59 |
emily | ah I guess it would still just use the regular ar by default? | 18:38:00 |
emily | not sure what ar we use on Darwin tbh | 18:38:00 |
sterni | I think GHC just uses AR, but that's only llvm-ar if useLLVM in nixpkgs (or does darwin use it?). As such it's also controlled by the global default LLVM version, so orthogonal to what we're doing | 19:21:28 |
emily | right | 19:30:57 |