Lemmih wrote:
On 3/22/06, Simon Marlow <[EMAIL PROTECTED]> wrote:
David Himmelstrup wrote:
Sat Mar 18 09:17:28 PST 2006 Lemmih <[EMAIL PROTECTED]>
* -fno-code shouldn't be a mode.
I've removed -fno-code from Main to make it work
equally well with --make and -c.
I've also allowed it not to write hi files unless
-fwrite-iface is given.
M ./ghc/compiler/main/CodeOutput.lhs +1
M ./ghc/compiler/main/DriverPipeline.hs -25 +4
M ./ghc/compiler/main/DynFlags.hs -4 +10
M ./ghc/compiler/main/HscMain.lhs -2 +4
M ./ghc/compiler/main/Main.hs -6 +7
I've just noticed a couple of problems with this. I'm off home now so I
haven't got time to investigate any further, but:
- -keep-s-files shouldn't turn on -fasm, since you can get .s files
from via-C compilation too. This is easily fixable.
- the hscMaybeAdjustLang thing was there to handle stuff like this:
$ ghc -C -fasm hello.hs
ghc-6.5.20060322: panic! (the 'impossible' happened)
(GHC version 6.5.20060322 for x86_64-unknown-linux):
pipeLoop: at phase As but I wanted to stop at phase HCc
there may be other effects, I'm not sure.
Hm, right. I'll revert the changes and return in a couple of days when
I've figured out how to simplify the pipeline enough to wrap my head
around it.
I'll add a test for that case, too. BTW, the driver tests are very
useful when playing with the pipeline code: just go into
testsuite/tests/ghc-regress/driver and say 'make'.
In particular, I've been thinking about refactoring out the
preprocessing to allow a full compilation plan to be generated before
it's executed, and, consequently, hoisting 'getOutputFilename' out of
the inner loop.
In fact, this is how it used to be done. One problem with that is that
you can't always generate the pipeline beforehand, because the {-#
OPTIONS_GHC #-} pragma might include -fvia-C, for example.
I'm aware that this part of the compiler resists comprehension to some
extent :-) By all means try to refactor it. I would point out, though,
that the current design is the result of several iterations, and IMO the
real problem is that the semantics we have to implement is just a bit weird.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
