summaryrefslogtreecommitdiff
path: root/compiler/main/DriverPipeline.hs
Commit message (Collapse)AuthorAgeFilesLines
* Module hierarchy: Iface (cf #13009)Sylvain Henry2020-01-061-1/+1
|
* Simplify mrStrGabor Greif2020-01-031-1/+1
|
* Pass ModDetails with (partial) ModIface in HscStatusÖmer Sinan Ağacan2019-11-291-19/+25
| | | | | | | | | | (Partial) ModIface and ModDetails are generated at the same time, but they're passed differently: ModIface is passed in HscStatus consturctors while ModDetails is returned in a tuple. This refactors ModDetails passing so that it's passed around with ModIface in HscStatus constructors. This makes the code more consistent and hopefully easier to understand: ModIface and ModDetails are really very closely related. It makes sense to treat them the same way.
* Only pass mod_location with HscRecomp instead of the entire ModSummaryÖmer Sinan Ağacan2019-11-131-7/+6
| | | | | | | | HscRecomp users only need the ModLocation of the module being compiled, so only pass that to users instead of the entire ModSummary Metric Decrease: T4801
* Return ModIface in compilation pipeline, remove IORef hack for generating ↵Ömer Sinan Ağacan2019-10-291-62/+61
| | | | | | | | | | | | | | | | | | | | | ModIfaces The compilation phases now optionally return ModIface (for phases that generate an interface, currently only HscOut when (re)compiling a file). The value is then used by compileOne' to return the generated interface with HomeModInfo (which is then used by the batch mode compiler when building rest of the tree). hscIncrementalMode also returns a DynFlags with plugin info, to be used in the rest of the pipeline. Unfortunately this introduces a (perhaps less bad) hack in place of the previous IORef: we now record the DynFlags used to generate the partial infterface in HscRecomp and use the same DynFlags when generating the full interface. I spent almost three days trying to understand what's changing in DynFlags that causes a backpack test to fail, but I couldn't figure it out. There's a FIXME added next to the field so hopefully someone who understands this better than I do will fix it leter.
* Refactor HscRecomp constructors:Ömer Sinan Ağacan2019-10-291-29/+22
| | | | | | | | | | | Make it evident in the constructors that the final interface is only available when HscStatus is not HscRecomp. (When HscStatus == HscRecomp we need to finish the compilation to get the final interface) `Maybe ModIface` return value of hscIncrementalCompile and the partial `expectIface` function are removed.
* Remove redundant -fno-cse optionsÖmer Sinan Ağacan2019-10-261-2/+0
| | | | | These were probably added with some GLOBAL_VARs, but those GLOBAL_VARs are now gone.
* Refactor, document, and optimize LLVM configuration loadingBen Gamari2019-10-071-2/+2
| | | | | | | | | | | | As described in the new Note [LLVM Configuration] in SysTools, we now load llvm-targets and llvm-passes lazily to avoid the overhead of doing so when -fllvm isn't used (also known as "the common case"). Noticed in #17003. Metric Decrease: T12234 T12150
* Clean up `#include`s in the compilerJohn Ericson2019-10-051-0/+1
| | | | | | | | - Remove unneeded ones - Use <..> for inter-package. Besides general clean up, helps distinguish between the RTS we link against vs the RTS we compile for.
* Refactor iface file generation:Ömer Sinan Ağacan2019-09-301-28/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit refactors interface file generation to allow information from the later passed (NCG, STG) to be stored in interface files. We achieve this by splitting interface file generation into two parts: * Partial interfaces, built based on the result of the core pipeline * A fully instantiated interface, which also contains the final fingerprints and can optionally contain information produced by the backend. This change is required by !1304 and !1530. -dynamic-too handling is refactored too: previously when generating code we'd branch on -dynamic-too *before* code generation, but now we do it after. (Original code written by @AndreasK in !1530) Performance ~~~~~~~~~~~ Before this patch interface files where created and immediately flushed to disk which made space leaks impossible. With this change we instead use NFData to force all iface related data structures to avoid space leaks. In the process of refactoring it was discovered that the code in the ToIface Module allocated a lot of thunks which were immediately forced when writing/forcing the interface file. So we made this module more strict to avoid creating many of those thunks. Bottom line is that allocations go down by about ~0.1% compared to master. Residency is not meaningfully different after this patch. Runtime was not benchmarked. Co-Authored-By: Andreas Klebinger <klebinger.andreas@gmx.at> Co-Authored-By: Ömer Sinan Ağacan <omer@well-typed.com>
* Just get RTS libs from its package confJohn Ericson2019-09-271-19/+0
| | | | | `rts.conf` already contains this exact information in its `extra-libraries` stanza.
* Fix LLVM version check yet againÖmer Sinan Ağacan2019-08-291-5/+5
| | | | | | | | | | | | | | | There were two problems with LLVM version checking: - The parser would only parse x and x.y formatted versions. E.g. 1.2.3 would be rejected. - The version check was too strict and would reject x.y formatted versions. E.g. when we support version 7 it'd reject 7.0 ("LLVM version 7.0") and only accept 7 ("LLVM version 7"). We now parse versions with arbitrarily deep minor numbering (x.y.z.t...) and accept versions as long as the major version matches the supported version (e.g. 7.1, 7.1.2, 7.1.2.3 ...).
* Remove LLVM_TARGET platform macrosJohn Ericson2019-07-141-1/+1
| | | | | Instead following @angerman's suggestion put them in the config file. Maybe we could re-key llvm-targets someday, but this is good for now.
* Remove most uses of TARGET platform macrosJohn Ericson2019-07-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These prevent multi-target builds. They were gotten rid of in 3 ways: 1. In the compiler itself, replacing `#if` with runtime `if`. In these cases, we care about the target platform still, but the target platform is dynamic so we must delay the elimination to run time. 2. In the compiler itself, replacing `TARGET` with `HOST`. There was just one bit of this, in some code splitting strings representing lists of paths. These paths are used by GHC itself, and not by the compiled binary. (They are compiler lookup paths, rather than RPATHS or something that does matter to the compiled binary, and thus would legitamentally be target-sensative.) As such, the path-splitting method only depends on where GHC runs and not where code it produces runs. This should have been `HOST` all along. 3. Changing the RTS. The RTS doesn't care about the target platform, full stop. 4. `includes/stg/HaskellMachRegs.h` This file is also included in the genapply executable. This is tricky because the RTS's host platform really is that utility's target platform. so that utility really really isn't multi-target either. But at least it isn't an installed part of GHC, but just a one-off tool when building the RTS. Lying with the `HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad. It's certainly better than the other way around of lying to the RTS though not to genapply. The RTS is more important, and it is installed, *and* this header is installed as part of the RTS.
* Fixes for LLVM 7Erik de Castro Lopo2019-06-241-2/+3
| | | | | | | LLVM version numberinf changed recently. Previously, releases were numbered 4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0". Fix requires for Llvm detection and some code.
* Move 'Platform' to ghc-bootJohn Ericson2019-06-191-1/+1
| | | | | | | ghc-pkg needs to be aware of platforms so it can figure out which subdire within the user package db to use. This is admittedly roundabout, but maybe Cabal could use the same notion of a platform as GHC to good affect too.
* Pass preprocessor options to C compiler when building foreign C files (#16737)Zejun Wu2019-06-071-4/+12
|
* Expose doCppNeil Mitchell2019-05-311-0/+1
|
* Improve targetContents code docsDaniel Gröber2019-05-301-4/+4
|
* Catch preprocessor errors in downsweepDaniel Gröber2019-05-301-1/+11
| | | | | | | | | | | | | | | | This changes the way preprocessor failures are presented to the user. Previously the user would simply get an unlocated message on stderr such as: `gcc' failed in phase `C pre-processor'. (Exit code: 1) Now at the problematic source file is mentioned: A.hs:1:1: error: `gcc' failed in phase `C pre-processor'. (Exit code: 1) This also makes live easier for GHC API clients as the preprocessor error is now thrown as a SourceError exception.
* Make downsweep return all errors per-module instead of throwing someDaniel Gröber2019-05-301-2/+5
| | | | | | | | This enables API clients to handle such errors instead of immideately crashing in the face of some kinds of user errors, which is arguably quite bad UX. Fixes #10887
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-10/+11
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* Allow using tagetContents for modules needing preprocessingDaniel Gröber2019-05-291-12/+35
| | | | | | | | | | | | | | | | | | This allows GHC API clients, most notably tooling such as Haskell-IDE-Engine, to pass unsaved files to GHC more easily. Currently when targetContents is used but the module requires preprocessing 'preprocessFile' simply throws an error because the pipeline does not support passing a buffer. This change extends `runPipeline` to allow passing the input buffer into the pipeline. Before proceeding with the actual pipeline loop the input buffer is immediately written out to a new tempfile. I briefly considered refactoring the pipeline at large to pass around in-memory buffers instead of files, but this seems needlessly complicated since no pipeline stages other than Hsc could really support this at the moment.
* Remove all target-specific portions of Config.hsJohn Ericson2019-05-141-2/+1
| | | | | | | | | | | | | | | | | | | 1. If GHC is to be multi-target, these cannot be baked in at compile time. 2. Compile-time flags have a higher maintenance than run-time flags. 3. The old way makes build system implementation (various bootstrapping details) with the thing being built. E.g. GHC doesn't need to care about which integer library *will* be used---this is purely a crutch so the build system doesn't need to pass flags later when using that library. 4. Experience with cross compilation in Nixpkgs has shown things work nicer when compiler's can *optionally* delegate the bootstrapping the package manager. The package manager knows the entire end-goal build plan, and thus can make top-down decisions on bootstrapping. GHC can just worry about GHC, not even core library like base and ghc-prim!
* Enable external interpreter when TH is requested but no internal interpreter ↵Alp Mestanogullari2019-05-061-2/+9
| | | | is available
* Add `-optcxx` option (#16477)Yuriy Syrovetskiy2019-04-081-12/+3
|
* Simplify monadic codeKrzysztof Gogolewski2019-03-191-5/+4
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-4/+4
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-03-091-7/+6
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-03-091-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Rip out object splittingBen Gamari2019-03-051-148/+18
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* Revert "compiler: Write .o files atomically. See #14533"Ben Gamari2019-03-041-6/+1
| | | | This reverts commit 0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d.
* Revert "compiler: Refactor: extract `withAtomicRename`"Ben Gamari2019-03-041-6/+7
| | | | This reverts commit e8a08f400744a860d1366c6680c8419d30f7cc2a.
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-02-211-7/+6
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-02-211-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Add support for ASM foreign files (.s) in TH (#16180)Sylvain Henry2019-01-201-4/+5
|
* Support generating HIE filesAlec Theriault2018-12-111-10/+28
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* Windows: Use the "big" PE object format on amd64Ben Gamari2018-12-061-1/+37
| | | | | | | | | | | | | | Test Plan: Do full build on Windows. Reviewers: AndreasK, Phyx Reviewed By: AndreasK Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15934 Differential Revision: https://phabricator.haskell.org/D5383
* Revert "driver: unconditionally disable relaxation when linking partially"Ryan Scott2018-08-221-4/+5
| | | | | | | | This reverts commit 1cc9061fce4270739677d475190fd6e890e8b1f9. This appears to break a clean build with certain versions of `ld.gold`. See https://phabricator.haskell.org/rGHC1cc9061fce42#132967.
* Introduce flag -keep-hscpp-filesroland2018-08-211-0/+2
| | | | | | | | | | | | | | Test Plan: `make test=T10869` Reviewers: mpickering, thomie, ezyang, bgamari Reviewed By: thomie, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #10869 Differential Revision: https://phabricator.haskell.org/D4861
* driver: unconditionally disable relaxation when linking partiallySergei Trofimovich2018-08-211-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In https://github.com/gentoo-haskell/gentoo-haskell/issues/704 user explicitly uses -Wl,--relax for most built binaries. Most of the time this works fine except for capi haskell code similar to the following: ```haskell {-# LANGUAGE CApiFFI #-} module Z where import Foreign.C foreign import capi "unistd.h close" c_close :: CInt -> IO CInt ``` In this case compilation fails as: ``` $ inplace/bin/ghc-stage2 -c Z.hs -optl-Wl,--relax -fforce-recomp ld: --relax and -r may not be used together ``` GHC's driver already disables relaxation on sparc as there relaxation is already a default mode. This change disables relaxation on partial linking for all platforms where linker is binutils linker. Reported-by: wmyrda Bug: https://github.com/gentoo-haskell/gentoo-haskell/issues/704 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: pass -optl-Wl,--relax in test above Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4888
* Fix space leaksSimon Marlow2018-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872
* Fix gcc.exe: error: CreateProcess: No such file or directoryMoritz Angermann2018-06-201-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | When GHC links binaries on windows, we pass a -L and -l flag to gcc for each dependency in the transitive dependency closure. As this will usually overflow the command argument limit on windows, we use response files to pass all arguments to gcc. gcc however internally passes only the -l flags via a response file to the collect2 command, but puts the -L flags on the command line. As such if we pass enough -L flags to gcc--even via a response file--we will eventually overflow the command line argument length limit due to gcc passing them to collect2 without resorting to a response file. To prevent this from happening we move all lirbaries into a shared temporary folder, and only need to pass a single -L flag to gcc. Ideally however this was fixed in gcc. Reviewers: bgamari, Phyx Reviewed By: bgamari Subscribers: erikd, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4762
* dead strip dylibs on macOSMoritz Angermann2018-05-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking dynamic libraries or executables, we compute the full transitive closure over the dependencies, and instruct the linker to link all dependencies. With deep dependency trees the number of transitive dependencies can grow quickly. macOS since the Sierra release has an upper limit on the load command sizes the linker parses when loading dynamic lirbaries. As such it is mandatory to keep the number of load commands (and their size) small on recent macOS releases. An approach that would just link direct dependencies as specified by the -package-id flag is insufficient, because GHC can inline across packages and the library or executable being linked could refer to symbols deep in the dependency tree. If we just recursively linked librarys and re-exported their symbols, this increases the number of symbols in libraries with many dependencies and ultimately puts excessive strain on the linker to the point where linking takes a lot longer than even the compilation of the modules. We can however build a list of symbols from the obejcts we want to link, and try to compute the libraries we need to link that contain those symbols from the transitive dependency closure. Luckily, we don't need to write this ourselves, but can use the ld64 `-dead_strip_dylibs` linker flag on macOS to achive the same result. This will link only the libraries that are actually referenced, which is usually a small subset of the full transitive dependency closure. As such we should stay within the load command size limit for almost all but pathological cases. Reviewers: bgamari Reviewed By: bgamari Subscribers: lelf, rwbarton, thomie, carter GHC Trac Issues: #14444 Differential Revision: https://phabricator.haskell.org/D4714
* Extract hard-coded LLVM opt flags into a fileKavon Farvardin2018-05-301-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | To resolve ticket #11295, I think it makes sense to stop hard-coding the pass sequences used by GHC when compiling with LLVM into the compiler itself. This patchset introduces a companion to the existing `llvm-targets` file called `llvm-passes`. The passes file is a simple association list that holds the default LLVM `opt` pass sequence used by GHC. This allows end users to easily save their favorite optimization flags when compiling with LLVM. The main benefit for ticket #11295 is that when adding a custom pass sequence, it tends to be an extremely long string that would be unsightly in the code. This is essentially part 1 of 2 for ticket #11295. Test Plan: ./validate Reviewers: bgamari, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4695
* Simplify -ddump-json implementationMatthew Pickering2018-05-131-2/+1
| | | | | | | | | | | | | | | | | | | This patch takes the much simpler route of whenever the compiler tries to output something. We just dump a JSON document there and then. I think this should be sufficient to work with and anything more refined quickly got complicated as it was necessary to demarcate message scopes and so on. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: Phyx, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14078 Differential Revision: https://phabricator.haskell.org/D4532
* Do not supply `-mcpu` if `-optlc` provides `-mcpu` already.Moritz Angermann2018-05-051-2/+3
| | | | | | | | | | Reviewers: bgamari Subscribers: thomie, carter GHC Trac Issues: #14982 Differential Revision: https://phabricator.haskell.org/D4548
* Support adding objects from THAlec Theriault2018-03-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | The user facing TH interface changes are: * 'addForeignFile' is renamed to 'addForeignSource' * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's * 'RawObject' is now a constructor for 'ForeignSrcLang' * 'qAddTempFile'/'addTempFile' let you request a temporary file from the compiler. Test Plan: unsure about this, added a TH test Reviewers: goldfire, bgamari, angerman Reviewed By: bgamari, angerman Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie GHC Trac Issues: #14298 Differential Revision: https://phabricator.haskell.org/D4217
* Remove splitEithers, use partitionEithers from baseÖmer Sinan Ağacan2018-03-121-2/+3
|
* Change how includes for input file directory worksTamar Christina2018-02-191-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC Used to only allow for one include mode, namely `-I`. The problem with `-I` includes is that it supercedes all other includes, including the system include paths. This is not a problem for paths requested by the user, but it is a problem for the ones we implicitly derive and add. In particular we add the source directory of the input file to the include path. This is problematic because it causes any file with the name of a system include, to inadvertently loop as the wrong file gets included. Since this is an implicitly include, and as far as I can tell, only done so local includes are found (as the sources given to GCC reside in a temp folder) then switch from `-I` to `-iquote`. This requires a submodule update for haddock Test Plan: ./validate Reviewers: austin, bgamari, hvr Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14312 Differential Revision: https://phabricator.haskell.org/D4080
View Lorry Controller Status