#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: simonmar (added) Comment: simonmar: you wrote in ticket:437#comment:18 (5 years ago):

It's not clear to me that changing optimisation settings should trigger recompilation: for example, you might have a large program compiled unoptimised, and then decide that you want to optimise just one or two modules, so you remove a few .o files, add -O and recompile.

Isn't stack supposed to rebuild a package when I specify a new set of ghc-options on the command line? As in e.g. 'stack build --ghc-

But these GHC users recently expressed their confusion about the current behavior: * #haskell user mtesseract: options=-O0'? It doesn't seem to rebuild anything here, irregardles of the ghc-options I specify. * reddit user [https://www.reddit.com/r/haskell/comments/4ro749/help_cabal_and_ghc_optimzat... winterland1989]:

when I change my own project's cabal from none to -O2, nothing will be recompiled, why?

Shall we add optimization flags to `fingerprintDynFlags` in `compiler/iface/FlagChecker.hs`? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10923#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Like `-fforce-recomp`? Or do you mean "`-fno-force-recomp`" (not sure whether that already exists)? I probably have made use of the current behavior before, though adding an `OPTIONS_GHC` pragma to a subset of the files is also a possibility. I've much more often been annoyed by needing to add `-fforce-recomp` when comparing the same program at different optimization levels. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10923#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"818760d68c0e5e4479a4f64fc863303ff5f23a3a/ghc" 818760d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="818760d68c0e5e4479a4f64fc863303ff5f23a3a" Fix #10923 by fingerprinting optimization level. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin, bgamari, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2509 GHC Trac Issues: #10923 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10923#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Shouldn’t you be fingerprinting all optimization-related flags, and not just the level? If I add `-fapply-fancy-transformation` the arguments, I would expect the compiler to rebuild the file. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10923#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10923: GHC should recompile if flags change -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: merge => new Comment: I think you’ll want a data structure that contains all the effective optimization flags, and not aliases like `-O`. This way, adding a flag that is implied by, say `-O`, would not cause recompilation. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10923#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler