#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The relevant bit of code is this in HscMain: {{{ -- If the module used TH splices when it was last -- compiled, then the recompilation check is not -- accurate enough (#481) and we must ignore -- it. However, if the module is stable (none of -- the modules it depends on, directly or -- indirectly, changed), then we *can* skip -- recompilation. This is why the SourceModified -- type contains SourceUnmodifiedAndStable, and -- it's pretty important: otherwise ghc --make -- would always recompile TH modules, even if -- nothing at all has changed. Stability is just -- the same check that make is doing for us in -- one-shot mode. case m_tc_result of Nothing | mi_used_th iface && not stable -> compile mb_old_hash (RecompBecause "TH") _ -> skip iface }}} I think the `&& not stable` is wrong. After interrupting the first compilation, the second compilation finds some modules to be stable and this overrides the TH check. Unfortunately if we just delete this condition, then TH will cause a *lot* of recompilation. Just re-running `ghc --make` on something you just recompiled will recompile all the TH modules and everything that depends on them. The stable check was always a bit of a hack though, to get around the fact that we don't have the information we really need, which is "did the object file change". Perhaps we just need to be more clever and store hashes of object files as dependencies when we're using TH. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

So I took a shot at that problem as well (making object files deterministic), taking a different approach than what was taken so far (instead of making uniques not appear in outputs, I'm trying to genrate

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Will take a look at the github branch (you wouldn't perhaps consider Phabricator instead? It's much easier to review code there) them deterministically) I'd be surprised if you can do that, we thought pretty hard about whether this was feasible and came to the conclusion that it probably wasn't, due to things like parallel builds, ghc --make needing to have unique supplies for multiple modules, and lazy I/O in the typechecker. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:3 simonmar]:

you wouldn't perhaps consider Phabricator instead? It's much easier to review code there

I will when I have it working and have some non-hacky commits; until then I prefer Github because it is much easier to update multi-commit patch series there than on Phab.

I'd be surprised if you can do that, we thought pretty hard about whether this was feasible and came to the conclusion that it probably wasn't, due to things like parallel builds, ghc --make needing to have unique supplies for multiple modules, and lazy I/O in the typechecker.

I'm not convinced either yet that it will work, and the `'r'` `UniqueSupply` in the global `--make` `HscEnv` is giving me some troubles at the current state, but so far I haven't found a reason why maintaining an independent "seed" for each module (as we know all modules ahead of time in a `--make` invocation) wouldn't cover at least the cases of multiple modules and `-j`. Regarding the lazy I/O in the typechecker, could you point me at where that happens? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:6 simonmar]:

So it seems like the uniques would have to be qualifed by the module/package names somehow.

Yes. I use the "`mod_index`" number, like `1` in the output `[1 of 3] Compiling A`, by which I index an array of `UniqueSupply` instead of having only one global one. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Yes, that scheme lacks "stability" against some use cases. Most prominently, adding a new module and importing it, thus turning e.g. `[1 of 3]` into `[2 of 4]`, will have us end up with different uniques and thus different `.o` files and different binaries (and the benefit of reduced `[TH]` compilations is lost for such changes). But the scheme should still solve the most common use cases: * A from-scratch build using the same code and same compiler would result in byte-identical outputs * Resuming a `--make` (`-j`) build after merely touching a file or changing a comment would result in byte-identical outputs * Resuming a `--make` (`-j`) build after changing the code in a module will would result in only the `.o` for that module to change (plus potentially some inlining sites if `-O` is on); `.o` files that were recompiled because of `[TH]` that generate identical `.o` outputs will allow for the identical-.o-file-`[TH]`-avoidance you proposed above The first point will allow us to get byte-reproducible binaries ala Debian's "reproducible builds"; until now due to Unique nondeterminism, this wasn't possible even under guaranteed input control and stopping-the- system-time sandboxes, as Nix does it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Why not instead extend the current mechanism to add non-determinism in

#14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:10 simonmar]: the code generator? From my side it's just a limitation of how much time I can sink into it. Making uniques not surface at all in the generated code would be great and cover more use cases, like being able to switch between `-c` and `--make` as you say, but an approach like I suggest would already cover the most common use cases (e.g. libraries and binaries built by cabal, Stack, Linux distributions would be deterministic, as they all use `--make`, and `[TH]` recompilation would be reduced), while (to my knowledge) not regressing any existing functionality (switching between `--make` and `-c` would remain as determinism-destroying as they were so far). Also, the two approaches don't seem to be competing -- it appears to me that in an ideal world, GHC would have neither internal variables appear in outputs, nor use any form of module-spanning "impure" internal state driven by `unsafePerformIO` as it has now. Using the module index is a quickest-and-easiest way to map the modules into a compact range of integers for easy array indexing. If this turns out to not be relevant for performance, then I could imagine also using the fully qualified module name or something similar, which might address the `-c` vs `--make` issue.

Relying on unique determinism is quite fragile and easily broken, and we have no way to know when that happens - at least with the current scheme we have some protection in the APIs for things like `UniqFM` so that it's hard to accidentally introduce non-determinism.

I'd argue that removing the possibility to access an `unsafePerformIO`-based number generator at all would be a much stronger guarantee that non-determinism cannot be introduced, is that not accurate? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14769#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler