summaryrefslogtreecommitdiff
path: root/compiler/llvmGen
Commit message (Collapse)AuthorAgeFilesLines
...
* LlvmCodeGen: Fix generation of malformed LLVM blocksErik de Castro Lopo2016-03-121-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 673efccb3b uncovered a bug in LLVM code generation that produced LLVM code that the LLVM compiler refused to compile: { clpH: br label %clpH } This may well be a bug in LLVM itself. The solution is to keep the existing entry label and rewrite the function as: { clpH: br label %nPV nPV: br label %nPV } Thanks to Ben Gamari for pointing me in the right direction on this one. Test Plan: Build GHC with BuildFlavour=quick-llvm Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1996 GHC Trac Issues: #11649
* Add MonadUnique instance for LlvmMBen Gamari2016-03-112-9/+16
| | | | | | | | | | Reviewers: erikd, austin Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1994
* Test for undef bugs in the LLVM backend when validatingReid Barton2016-01-271-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | In an attempt to catch bugs involving using undef values, replace undef literals by values likely to cause crashes or test failures. We do this only when validating since it is a deoptimization. This depends on D1857 to catch such bugs in the RTS (such as #11487). Test Plan: Did a build with ``` BuildFlavour = quick-llvm SRC_HC_OPTS_STAGE1 = -fllvm-fill-undef-with-garbage ``` The build crashed when running ghc-stage2, as expected. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1858
* Typos in commentsGabor Greif2016-01-271-1/+1
|
* Remove some redundant definitions/constraintsHerbert Valerio Riedel2015-12-311-1/+0
| | | | | | Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-312-7/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* LLVM backend: Show expected LLVM version in warnings/errorsÖmer Sinan Ağacan2015-12-182-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before: [1 of 1] Compiling Main ( Main.hs, Main.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... After: [1 of 1] Compiling Main ( Main.hs, Main.o ) You are using an unsupported version of LLVM! Currently only 3.7 is supported. We will try though... Before: [1 of 1] Compiling Main ( Main.hs, Main.o ) <no location info>: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt After: [1 of 1] Compiling Main ( Main.hs, Main.o ) <no location info>: error: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM 3.7 ghc-stage1: could not execute: opt Reviewers: austin, rwbarton, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1658
* Make HasDynFlags more transformers friendlyHerbert Valerio Riedel2015-12-081-5/+5
| | | | | | | | | | | | | | | | | Ideally, we'd have the more general instance (MonadTrans t, Monad m, HasDynFlags m) => HasDynFlags (t m) where getDynFlags = lift getDynFlags definition. However, that one would overlap with the `HasDynFlags (GhcT m)` instance. Instead we define instances for a couple of common Monad transformers explicitly in order to avoid nasty overlapping instances. This is a preparatory refactoring for #10874 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1581
* Implement warnings for Semigroups as parent of MonoidDavid Luposchainsky2015-11-291-0/+10
| | | | | | | | | | | | | | | | | | | | | This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-124-12/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405
* cmm: Expose machine's stack and return address registerBen Gamari2015-11-011-0/+1
| | | | | | | | | | We will need to use these to setup proper unwinding information for the stg_stop_thread closure. This pokes a hole in the STG abstraction, exposing the machine's stack pointer register so that we can accomplish this. We also expose a dummy return address register, which corresponds to the register used to hold the DWARF return address. Differential Revision: https://phabricator.haskell.org/D1225
* llvmGen: Really fix build with ClangErik de Castro Lopo2015-11-011-5/+6
| | | | | | | | | | Test Plan: Build with Clang and GCC Reviewers: austin, thomie, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1414
* llvmGen: Fix build with ClangErik de Castro Lopo2015-11-011-2/+2
| | | | | | | | | | | | | Another weird case of Clang not accepting whitespace in CPP that GCC accepts without a problem. Test Plan: Build with Clang and GCC Reviewers: austin, thomie, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1409
* Add subWordC# on x86ishNikita Karetnikov2015-10-311-2/+11
| | | | | | | | | | | | | | | This adds a subWordC# primop which implements subtraction with overflow reporting. Reviewers: tibbe, goldfire, rwbarton, bgamari, austin, hvr Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1334 GHC Trac Issues: #10962
* Make Monad/Applicative instances MRP-friendlyHerbert Valerio Riedel2015-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
* Fix GHCi on Arm (#10375).Erik de Castro Lopo2015-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Arm has two instruction sets, Arm and Thumb, and an execution mode for each. Executing Arm code in Thumb mode or vice-versa will likely result in an Illegal instruction exception. Furthermore, Haskell code compiled via LLVM was generating Arm instructions while C code compiled via GCC was generating Thumb code by default. When these two object code types were being linked by the system linker, all was fine, because the system linker knows how to jump and call from one instruction set to the other. The first problem was with GHCi's object code loader which did not know about Thumb vs Arm. When loading an object file `StgCRun` would jump into the loaded object which could change the mode causing a crash after it returned. This was fixed by forcing all C code to generate Arm instructions by passing `-marm` to GCC. The second problem was the `mkJumpToAddr` function which was generating Thumb instructions. Changing that to generate Arm instructions instead results in a working GHCi on Arm. Test Plan: validate on x86_64 and arm Reviewers: bgamari, austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1323 GHC Trac Issues: #10375
* Switch to LLVM version 3.7Erik de Castro Lopo2015-10-144-27/+23
| | | | | | | | | | | | | | | | | | | | | | | | Before this commit, GHC only supported LLVM 3.6. Now it only supports LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier do not work on AArch64/Arm64, but 3.7 does. Also: * Add CC_Ghc constructor to LlvmCallConvention. * Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with a single `supportedLlvmVersion` variable. * Get `supportedLlvmVersion` from version specified in configure.ac. * Drop llvmVersion field from DynFlags (no longer needed because only one version is supported). Test Plan: Validate on x86_64 and arm Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1320 GHC Trac Issues: #10953
* Revert "Switch to LLVM version 3.7"Erik de Castro Lopo2015-10-104-23/+29
| | | | | | Pushed by mistacke before it was ready. This reverts commit 5dc3db743ec477978b9727a313951be44dbd170f.
* Switch to LLVM version 3.7Erik de Castro Lopo2015-10-104-32/+26
|
* LLVM: Factor out accumulation of LLVM statements and variablesBen Gamari2015-10-021-197/+189
| | | | | | | | | | | | | | | | | | | | | | The LLVM code generator currently has a rather large amount of boilerplate devoted to piping around and building up various AST elements. This is rather unfortunate for a language which prides itself on ease of abstraction and detracts from readability. Here I continue a refactoring that I originally suggested in D991, using `WriterT` to factor out this pattern. `WriterT` is in general a bit problematic from an evaluation perspective, but the expressions here are small enough that it should be a problem in practice. Test Plan: Validate Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1286
* LLVM: Implement atomic operations in terms of LLVM primitivesBen Gamari2015-10-025-17/+124
| | | | | | | | | | | | | | | | | | | This fixes Trac #7883. This adds proper support for, * `MO_AtomicRMW` * `MO_AtomicWrite` * `MO_CmpXChg` Test Plan: Validate Reviewers: rrnewton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1282 GHC Trac Issues: #7883
* Annotate CmmBranch with an optional likely targetSimon Marlow2015-09-231-1/+1
| | | | | | | | | | | | | | | | | Summary: This allows the code generator to give hints to later code generation steps about which branch is most likely to be taken. Right now it is only taken into account in one place: a special case in CmmContFlowOpt that swapped branches over to maximise the chance of fallthrough, which is now disabled when there is a likelihood setting. Test Plan: validate Reviewers: austin, simonpj, bgamari, ezyang, tibbe Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1273
* llvmGen: Rework LLVM manglerBen Gamari2015-08-061-102/+81
| | | | | | | | | | | | | | | | | | | | The LLVM mangler does not currently transform AVX instructions on x86-64 platforms, due to a missing #include. Also, it is significantly more complicated than necessary, due to the file into sections (not needed anymore), and is sensitive to the details of the whitespace in the assembly. Author: dobenour Test Plan: Validation on x86-64, x86-32, and ARM Reviewers: austin Subscribers: thomie, bgamari, rwbarton Differential Revision: https://phabricator.haskell.org/D1034 GHC Trac Issues: #10394
* Typos in comments [skip ci]Gabor Greif2015-08-031-1/+1
|
* Support MO_U_QuotRem2 in LLVM backendMichal Terepeta2015-08-031-0/+72
| | | | | | | | | | | | | | | | | | | This adds support for MO_U_QuotRem2 in LLVM backend. Similarly to MO_U_Mul2 we use the standard LLVM instructions (in this case 'udiv' and 'urem') but do the computation on double the word width (e.g., for 64-bit we will do them on 128 registers). Test Plan: validate Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1100 GHC Trac Issues: #9430
* LlvmCodeGen: add support for MO_U_Mul2 CallishMachOpMichal Terepeta2015-07-201-0/+34
| | | | | | | | | | | | | | | | | | | This adds support MO_U_Mul2 to the LLVM backend by simply using 'mul' instruction but operating at twice the bit width (e.g., for 64 bit words we will generate mul that operates on 128 bits and then extract the two 64 bit values for the result of the CallishMachOp). Test Plan: validate Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1068 GHC Trac Issues: #9430
* Support MO_{Add,Sub}IntC and MO_Add2 in the LLVM backendMichal Terepeta2015-07-044-4/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | This includes: - Adding new LlvmType called LMStructP that represents an unpacked struct (this is necessary since LLVM's instructions the llvm.sadd.with.overflow.* return an unpacked struct). - Modifications to LlvmCodeGen.CodeGen to generate the LLVM instructions for the primops. - Modifications to StgCmmPrim to actually use those three instructions if we use the LLVM backend (so far they were only used for NCG). Test Plan: validate Reviewers: austin, rwbarton, bgamari Reviewed By: bgamari Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D991 GHC Trac Issues: #9430
* Encode alignment in MO_Memcpy and friendsBen Gamari2015-06-161-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Alignment needs to be a compile-time constant. Previously the code generators had to jump through hoops to ensure this was the case as the alignment was passed as a CmmExpr in the arguments list. Now we take care of this up front. This fixes #8131. Authored-by: Reid Barton <rwbarton@gmail.com> Dusted-off-by: Ben Gamari <ben@smart-cactus.org> Tests for T8131 Test Plan: Validate Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: bgamari, carter, thomie Differential Revision: https://phabricator.haskell.org/D624 GHC Trac Issues: #8131
* Remove unneeded compatibility with LLVM < 3.6Michal Terepeta2015-05-191-35/+9
| | | | | | | | | | | Since GHC requires at least LLVM 3.6, some of the special cases (for, e.g., LLVM 2.8 or 2.9) in the LLVM CodeGen can be simply removed. Reviewed By: rwbarton, austin Differential Revision: https://phabricator.haskell.org/D884 GHC Trac Issues: #10074
* Remove LlvmCodeGen panic variants.Edward Z. Yang2015-04-143-28/+3
| | | | | | | | | | | | It's pretty irritating having hasktags with multiple top-level declarations with the same type; hasktags can't figure out which declaration you actually wanted. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewed By: dterei, austin Differential Revision: https://phabricator.haskell.org/D819
* Refactor the story around switches (#10137)Joachim Breitner2015-03-301-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This re-implements the code generation for case expressions at the Stg → Cmm level, both for data type cases as well as for integral literal cases. (Cases on float are still treated as before). The goal is to allow for fancier strategies in implementing them, for a cleaner separation of the strategy from the gritty details of Cmm, and to run this later than the Common Block Optimization, allowing for one way to attack #10124. The new module CmmSwitch contains a number of notes explaining this changes. For example, it creates larger consecutive jump tables than the previous code, if possible. nofib shows little significant overall improvement of runtime. The rather large wobbling comes from changes in the code block order (see #8082, not much we can do about it). But the decrease in code size alone makes this worthwhile. ``` Program Size Allocs Runtime Elapsed TotalMem Min -1.8% 0.0% -6.1% -6.1% -2.9% Max -0.7% +0.0% +5.6% +5.7% +7.8% Geometric Mean -1.4% -0.0% -0.3% -0.3% +0.0% ``` Compilation time increases slightly: ``` -1 s.d. ----- -2.0% +1 s.d. ----- +2.5% Average ----- +0.3% ``` The test case T783 regresses a lot, but it is the only one exhibiting any regression. The cause is the changed order of branches in an if-then-else tree, which makes the hoople data flow analysis traverse the blocks in a suboptimal order. Reverting that gets rid of this regression, but has a consistent, if only very small (+0.2%), negative effect on runtime. So I conclude that this test is an extreme outlier and no reason to change the code. Differential Revision: https://phabricator.haskell.org/D720
* llvmGen: move to LLVM 3.6 exclusivelyBen Gamari2015-02-098-166/+72
| | | | | | | | | | | | | | | | | | | Summary: Rework llvmGen to use LLVM 3.6 exclusively. The plans for the 7.12 release are to ship LLVM alongside GHC in the interests of user (and developer) sanity. Along the way, refactor TNTC support to take advantage of the new `prefix` data support in LLVM 3.6. This allows us to drop the section-reordering component of the LLVM mangler. Test Plan: Validate, look at emitted code Reviewers: dterei, austin, scpmw Reviewed By: austin Subscribers: erikd, awson, spacekitteh, thomie, carter Differential Revision: https://phabricator.haskell.org/D530 GHC Trac Issues: #10074
* LlvmCodeGen cross-compiling fixes (#9895)Erik de Castro Lopo2014-12-291-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: * Throw an error when cross-compiling without a target definition. When cross compiling via LLVM, a target 'datalayout' and 'triple' must be defined or LLVM will generate code for the compile host instead of the compile target. * Add aarch64-unknown-linux-gnu target. The datalayout and triple lines were found by using clang to compile a small C program and -emit-llvm to get the LLVM IR output. Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com> Test Plan: validate Reviewers: rwbarton, carter, hvr, bgamari, austin Reviewed By: austin Subscribers: carter, thomie, garious Differential Revision: https://phabricator.haskell.org/D585 GHC Trac Issues: #9895
* Add unwind information to CmmPeter Wortmann2014-12-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Unwind information allows the debugger to discover more information about a program state, by allowing it to "reconstruct" other states of the program. In practice, this means that we explain to the debugger how to unravel stack frames, which comes down mostly to explaining how to find their Sp and Ip register values. * We declare yet another new constructor for CmmNode - and this time there's actually little choice, as unwind information can and will change mid-block. We don't actually make use of these capabilities, and back-end support would be tricky (generate new labels?), but it feels like the right way to do it. * Even though we only use it for Sp so far, we allow CmmUnwind to specify unwind information for any register. This is pretty cheap and could come in useful in future. * We allow full CmmExpr expressions for specifying unwind values. The advantage here is that we don't have to make up new syntax, and can e.g. use the WDS macro directly. On the other hand, the back-end will now have to simplify the expression until it can sensibly be converted into DWARF byte code - a process which might fail, yielding NCG panics. On the other hand, when you're writing Cmm by hand you really ought to know what you're doing. (From Phabricator D169)
* Tick scopesPeter Wortmann2014-12-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | This patch solves the scoping problem of CmmTick nodes: If we just put CmmTicks into blocks we have no idea what exactly they are meant to cover. Here we introduce tick scopes, which allow us to create sub-scopes and merged scopes easily. Notes: * Given that the code often passes Cmm around "head-less", we have to make sure that its intended scope does not get lost. To keep the amount of passing-around to a minimum we define a CmmAGraphScoped type synonym here that just bundles the scope with a portion of Cmm to be assembled later. * We introduce new scopes at somewhat random places, aligning with getCode calls. This works surprisingly well, but we might have to add new scopes into the mix later on if we find things too be too coarse-grained. (From Phabricator D169)
* Source notes (Cmm support)Peter Wortmann2014-12-161-0/+1
| | | | | | | | | | | | | | | | | | | | This patch adds CmmTick nodes to Cmm code. This is relatively straight-forward, but also not very useful, as many blocks will simply end up with no annotations whatosever. Notes: * We use this design over, say, putting ticks into the entry node of all blocks, as it seems to work better alongside existing optimisations. Now granted, the reason for this is that currently GHC's main Cmm optimisations seem to mainly reorganize and merge code, so this might change in the future. * We have the Cmm parser generate a few source notes as well. This is relatively easy to do - worst part is that it complicates the CmmParse implementation a bit. (From Phabricator D169)
* llvmGen: Compatibility with LLVM 3.5 (re #9142)Ben Gamari2014-11-215-31/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to changes in LLVM 3.5 aliases now may only refer to definitions. Previously to handle symbols defined outside of the current commpilation unit GHC would emit both an `external` declaration, as well as an alias pointing to it, e.g., @stg_BCO_info = external global i8 @stg_BCO_info$alias = alias private i8* @stg_BCO_info Where references to `stg_BCO_info` will use the alias `stg_BCO_info$alias`. This is not permitted under the new alias behavior, resulting in errors resembling, Alias must point to a definition i8* @"stg_BCO_info$alias" To fix this, we invert the naming relationship between aliases and definitions. That is, now the symbol definition takes the name `@stg_BCO_info$def` and references use the actual name, `@stg_BCO_info`. This means the external symbols can be handled by simply emitting an `external` declaration, @stg_BCO_info = external global i8 Whereas in the case of a forward declaration we emit, @stg_BCO_info = alias private i8* @stg_BCO_info$def Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D155
* Revert change to alias handling in ppLlvmGlobal introduced in d87fa34, which ↵Luke Iannini2014-11-211-1/+1
| | | | | | requires LLVM 3.6. Signed-off-by: Austin Seipp <austin@well-typed.com>
* arm64: 64bit iOS and SMP support (#7942)Luke Iannini2014-11-192-1/+4
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Allow -dead_strip linking on platforms with .subsections_via_symbolsMoritz Angermann2014-11-191-1/+7
| | | | | | | | | | | | | | | | | Summary: This allows to link objects produced with the llvm code generator to be linked with -dead_strip. This applies to at least the iOS cross compiler and OS X compiler. Signed-off-by: Moritz Angermann <moritz@lichtzwerge.de> Test Plan: Create a ffi library and link it with -dead_strip. If the resulting binary does not crash, the patch works as advertised. Reviewers: rwbarton, simonmar, hvr, dterei, mzero, ezyang, austin Reviewed By: dterei, ezyang, austin Subscribers: thomie, mzero, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D206
* Revert "Place static closures in their own section."Edward Z. Yang2014-10-201-1/+0
| | | | | | | | | | This reverts commit b23ba2a7d612c6b466521399b33fe9aacf5c4f75. Conflicts: compiler/cmm/PprCmmDecl.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/X86/Ppr.hs
* Place static closures in their own section.Edward Z. Yang2014-10-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: The primary reason for doing this is assisting debuggability: if static closures are all in the same section, they are guaranteed to be adjacent to one another. This will help later when we add some code that takes section start/end and uses this to sanity-check the sections. Part of remove HEAP_ALLOCED patch set (#8199) Signed-off-by: Edward Z. Yang <ezyang@mit.edu> Test Plan: validate Reviewers: simonmar, austin Subscribers: simonmar, ezyang, carter, thomie Differential Revision: https://phabricator.haskell.org/D263 GHC Trac Issues: #8199
* Stop exporting, and stop using, functions marked as deprecatedThomas Miedema2014-09-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Don't export `getUs` and `getUniqueUs`. `UniqSM` has a `MonadUnique` instance: instance MonadUnique UniqSM where getUniqueSupplyM = getUs getUniqueM = getUniqueUs getUniquesM = getUniquesUs Commandline-fu used: git grep -l 'getUs\>' | grep -v compiler/basicTypes/UniqSupply.lhs | xargs sed -i 's/getUs/getUniqueSupplyM/g git grep -l 'getUniqueUs\>' | grep -v combiler/basicTypes/UniqSupply.lhs | xargs sed -i 's/getUniqueUs/getUniqueM/g' Follow up on b522d3a3f970a043397a0d6556ca555648e7a9c3 Reviewed By: austin, hvr Differential Revision: https://phabricator.haskell.org/D220
* Make Applicative a superclass of MonadAustin Seipp2014-09-091-0/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This includes pretty much all the changes needed to make `Applicative` a superclass of `Monad` finally. There's mostly reshuffling in the interests of avoid orphans and boot files, but luckily we can resolve all of them, pretty much. The only catch was that Alternative/MonadPlus also had to go into Prelude to avoid this. As a result, we must update the hsc2hs and haddock submodules. Signed-off-by: Austin Seipp <austin@well-typed.com> Test Plan: Build things, they might not explode horribly. Reviewers: hvr, simonmar Subscribers: simonmar Differential Revision: https://phabricator.haskell.org/D13
* `M-x delete-trailing-whitespace` & `M-x untabify`...Herbert Valerio Riedel2014-08-311-7/+7
| | | | | | ...some files more or less recently touched by me [ci skip]
* Add MO_AddIntC, MO_SubIntC MachOps and implement in X86 backendReid Barton2014-08-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Summary: These MachOps are used by addIntC# and subIntC#, which in turn are used in integer-gmp when adding or subtracting small Integers. The following benchmark shows a ~6% speedup after this commit on x86_64 (building GHC with BuildFlavour=perf). {-# LANGUAGE MagicHash #-} import GHC.Exts import Criterion.Main count :: Int -> Integer count (I# n#) = go n# 0 where go :: Int# -> Integer -> Integer go 0# acc = acc go n# acc = go (n# -# 1#) $! acc + 1 main = defaultMain [bgroup "count" [bench "100" $ whnf count 100]] Differential Revision: https://phabricator.haskell.org/D140
* LlvmMangler: Be more selective when mangling object typesBen Gamari2014-08-151-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We previously did a wholesale replace of `%function` to `%object` to mangle object `.type` annotations. This is bad as it can end up replacing appearances of `"%function"` in the user's code. We now look for a proper `.type` keyword before performing the replacement. Thanks to @rwbarton for pointing out the bug. Test Plan: Previously, $ echo 'main = putStrLn "@function"' > test.hs $ ghc -fllvm test.hs $ ./test @object Now, $ echo 'main = putStrLn "@function"' > test.hs $ ghc -fllvm test.hs $ ./test @function Reviewers: rwbarton, austin Reviewed By: rwbarton, austin Subscribers: phaskell, simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D150 GHC Trac Issues: #9439
* Implement new CLZ and CTZ primops (re #9340)Herbert Valerio Riedel2014-08-141-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | This implements the new primops clz#, clz32#, clz64#, ctz#, ctz32#, ctz64# which provide efficient implementations of the popular count-leading-zero and count-trailing-zero respectively (see testcase for a pure Haskell reference implementation). On x86, NCG as well as LLVM generates code based on the BSF/BSR instructions (which need extra logic to make the 0-case well-defined). Test Plan: validate and succesful tests on i686 and amd64 Reviewers: rwbarton, simonmar, ezyang, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D144 GHC Trac Issues: #9340
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Re-add more primops for atomic ops on byte arraysJohan Tibell2014-06-303-30/+66
| | | | | | | | | | | | | | | | | | | | | | | This is the second attempt to add this functionality. The first attempt was reverted in 950fcae46a82569e7cd1fba1637a23b419e00ecd, due to register allocator failure on x86. Given how the register allocator currently works, we don't have enough registers on x86 to support cmpxchg using complicated addressing modes. Instead we fall back to a simpler addressing mode on x86. Adds the following primops: * atomicReadIntArray# * atomicWriteIntArray# * fetchSubIntArray# * fetchOrIntArray# * fetchXorIntArray# * fetchAndIntArray# Makes these pre-existing out-of-line primops inline: * fetchAddIntArray# * casIntArray#
View Lorry Controller Status