Opened 3 years ago

Last modified 2 years ago

#10923 new bug

GHC should recompile if flags change

Reported by: ezyang Owned by:
Priority: low Milestone:
Component: Compiler Version: 7.10.2
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Example:

ezyang@sabre:~$ rm B.hi
ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs 
ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghc -c B.hs -O
compilation IS NOT required

Pretty minor, but would be nice to have fixed.

Change History (9)

comment:1 Changed 2 years ago by thomie

Cc: simonmar added

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.

But these GHC users recently expressed their confusion about the current behavior:

  • #haskell user mtesseract:

    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-options=-O0'? It doesn't seem to rebuild anything here, irregardles of the ghc-options I specify.

  • reddit user 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?

comment:2 Changed 2 years ago by ezyang

I am sure that there are some people who are using the old behavior. Maybe there needs to be a flag flipping between the two behaviors.

comment:3 Changed 2 years ago 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.

comment:4 Changed 2 years ago by simonmar

Arguably it's wrong for GHC to say "ok, done" when the object file on disk is not the same as the one it would have produced if it had recompiled. (for some suitable definition of "the same"). So I'm ok with changing this, especially if it's confusing people.

comment:5 Changed 2 years ago by Edward Z. Yang <ezyang@…>

In 818760d/ghc:

Fix #10923 by fingerprinting optimization level.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: simonmar, austin, bgamari, thomie, rwbarton

Differential Revision: https://phabricator.haskell.org/D2509

GHC Trac Issues: #10923

comment:6 Changed 2 years ago by ezyang

Status: newmerge

bgamari, do you think we should merge this? I'm happy either way.

comment:7 Changed 2 years ago 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.

comment:8 Changed 2 years ago by ezyang

I guess that's true. (Ugh, there's certainly a lot of them.)

comment:9 Changed 2 years ago by nomeata

Status: mergenew

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.

Note: See TracTickets for help on using tickets.