| 23 Nov 2021 |
 Alyssa Ross | sternenseemann: although while I have you I am curious, doesn't pgo mean non-reproducibility? | 22:15:47 |
 sterni | Alyssa Ross: it does not actually and it is a common misconception I have discovered | 22:16:08 |
| sterni | PGO profiling data only is like code path analysis, so if the analyzed code is deterministic and you feed it the same input every time it'll come up with the same profiling data | 22:16:55 |
| sterni | it is also not machine dependent as far as I can tell (not sure if instruction sets are relevant though?) | 22:17:22 |
| sterni | for foot PGO I made a patch which allowed seeding the input data generation with a fixed start value | 22:17:48 |
| Alyssa Ross | oh cool! | 22:17:55 |
| sterni | and I you can reproduce the same output store path for foot on multiple machines | 22:18:03 |
| sterni | so ironically gcc can do reproducible PGO, but not of itself | 22:18:19 |
| Alyssa Ross | amazing | 22:41:39 |
| sterni | probably the part of the build system which runs the partial profiling compiler is racy | 22:43:11 |
| sterni | but I suspect it's non trivial to debug | 22:43:24 |
| sterni | I think baloo even tried -j1 to no avail | 22:43:32 |
| sterni | https://github.com/NixOS/nixpkgs/pull/112928#issuecomment-809714907 | 22:46:07 |
| sterni | ah hm differences between different machines | 22:46:36 |
| sterni | ominous | 22:46:37 |
| 24 Nov 2021 |
| sterni | John Ericson: getting the increasing sense that our GHC derivations are ever so subtly incorrect, but somehow work-ish (?) | 11:00:38 |
| sterni | like why the hell do we pass buildPackages.llvmPackages, but then go on to put it in depsBuildTarget | 11:00:58 |
| sterni | also I feel like the LLVM of the build (bootstrapping) GHC somehow leaks into the build environment for the actual GHC because it just complains about having the wrong LLVM version | 11:02:03 |
| sterni | which checks out because we propagate llvm for some reason | 11:02:18 |
| sterni | I wonder if this is unnecessary because we usually wrap the compiler as well? | 11:02:35 |
| sterni | the binaries aren't wrapped maybe that's where this stems from | 11:09:00 |
| sterni | oh and we don't put llvm in the wrapper for the normal ones as well | 11:09:31 |
 John Ericson | sterni: well, I say the solution is just to get rid of the old stuff! :) | 17:35:45 |
| John Ericson | https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5965 | 17:35:58 |
 andi- | This is likely the most fitting channel for this question: Do we have some sort of rpath minification in nixpkgs? I'm currently assuming every library in buildInputs could potentially end up in the rpath of each binary that we build, right? | 22:44:31 |
 symphorien | What is the shrink-rpath step of fixupphase ? | 22:46:15 |
| andi- | oh, that is in patchelf | 22:47:12 |
| andi- | I was grepping for various terms but not for shrink | 22:47:32 |
| andi- | and it works exactly as I was about to implement it. Thanks for the pointer symphorien | 22:49:08 |
| symphorien | Actually I don't really know what it does | 22:50:27 |
