summaryrefslogtreecommitdiff
path: root/compiler/cmm
Commit message (Collapse)AuthorAgeFilesLines
...
* BlockId: remove BlockMap and BlockSet synonymsMichal Terepeta2016-12-0813-75/+64
| | | | | | | | | | | | | | | | | | | | This continues removal of `BlockId` module in favor of Hoopl's `Label`. Most of the changes here are mechanical, apart from the orphan `Outputable` instances for `LabelMap` and `LabelSet`. For now I've moved them to `cmm/Hoopl`, since it's already trying to manage all imports from Hoopl (to avoid any collisions). Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2800
* Reduce the size of string literals in binaries.Thijs Alkemade2016-12-064-4/+13
| | | | | | | | | | | | | | | Removed the alignment for strings and mark then as cstring sections in the generated asm so the linker can merge duplicate sections. Reviewers: rwbarton, trofi, austin, trommler, simonmar, hvr, bgamari Reviewed By: hvr, bgamari Subscribers: simonpj, hvr, thomie Differential Revision: https://phabricator.haskell.org/D1290 GHC Trac Issues: #9577
* Hoopl/Dataflow: use block-oriented interfaceMichal Terepeta2016-11-294-292/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the new interface for dataflow analysis, where transfer functions operate on a whole basic block. The main changes are: - Hoopl.Dataflow: implement the new interface and remove the old code; expose a utility function to do a strict fold over the nodes of a basic block (for analyses that do want to look at all the nodes) - Refactor all the analyses to use the new interface. One of the nice effects is that we can remove the `analyzeFwdBlocks` hack that ignored the middle nodes (that existed for analyses that didn't need to go over all the nodes). Now this is no longer a special case and fits well with the new interface. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate, earlier version of the patch had assertions comparing the results with the old implementation Reviewers: erikd, austin, simonmar, hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: goldfire, erikd, thomie Differential Revision: https://phabricator.haskell.org/D2754
* Remove most functions from cmm/BlockIdMichal Terepeta2016-11-293-25/+23
| | | | | | | | | | | | | | | | | | | | It seems that `BlockId` module could simply go away in favor of Hoopl's `Label`. This is the first step to do that. In a few places I had to add some type signatures, but most of them seem to help with code readability. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2765
* Use newBlockId instead of newLabelCBen Gamari2016-11-292-2/+6
| | | | | | | | | | | | | | | This seems like a clearer name and the fewer functions that one needs to remember, the better. Test Plan: validate Reviewers: austin, simonmar, michalt Reviewed By: simonmar, michalt Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2735
* Minor cleanup of foldRegs{Used,Defd}Michal Terepeta2016-11-292-43/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the two functions strict in the accumulator - it seems that there are only two users of those functions: `CmmLive` and `CmmSink` and in both cases the strict fold fits better. The commit also removes a few unused functions (`filterRegsUsed`), instances (for `Maybe` and `RegSet`) and gets rid of unnecessary inculde of `HsVersions.h`. The performance effect of avoiding unnecessary thunks is mostly negligible, although we do allocate a tiny bit less (nofib's section on compile allocations): ``` -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% ``` Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2723
* add ieee754 next* functions to math_funsBen Gamari2016-11-211-1/+6
| | | | | | | | | | | | Reviewers: austin, simonmar, trofi, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2671 GHC Trac Issues: #12802
* LLVM generate llvm.expect for conditional branchesAlex Biehl2016-11-171-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds likeliness annotations to heap and and stack checks and modifies the llvm codegen to recognize those to help it generate better code. So with this patch ``` ... if ((Sp + 8) - 24 < SpLim) (likely: False) goto c23c; else goto c23d; ... ``` roughly generates: ``` %ln23k = icmp ult i64 %ln23j, %SpLim_Arg %ln23m = call ccc i1 (i1, i1) @llvm.expect.i1( i1 %ln23k, i1 0 ) br i1 %ln23m, label %c23c, label %c23d ``` Note the call to `llvm.expect` which denotes the expected result for the comparison. Test Plan: Look at assembler code with and without this patch. If the heap-checks moved out of the way we are happy. Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2688 GHC Trac Issues: #8321
* Remove CONSTR_STATICSimon Marlow2016-11-142-32/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 GHC Trac Issues: #12455
* Hoopl/Dataflow: make the module more self-containedMichal Terepeta2016-11-025-52/+82
| | | | | | | | | | | | | | | | | | | | | | | | | This makes the GHC's Dataflow module more self-contained by also forking the `DataflowLattice` (instead of only the analysis algorithm). Effects/benefits: - We no longer need to use the deprecated Hoopl functions (and can remove `-fno-warn-warnings-deprecations` from two modules). - We can remove the unnecessary `Label` parameter of `JoinFun` (already ignored in all our implementations). - We no longer mix Hoopl's `Dataflow` module and GHC's one. - We can replace some calls to lazy folds in Hoopl with the strict ones (see `joinOutFacts` and `mkFactBase`). Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2660
* Sparc*: Prevent GHC from doing unaligned accessesErik de Castro Lopo2016-11-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | This is specifically for the C backend on Sparc64 (which has no native backend) but is also required for Sparc when building un-registerised. Bug reported via Debian (patch included): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842780 Test Plan: validate Reviewers: hvr, Phyx, bgamari, austin, simonmar Reviewed By: Phyx Subscribers: jrtc27, thomie Differential Revision: https://phabricator.haskell.org/D2661 GHC Trac Issues: #12793
* CmmUtils: remove the last dataflow functionsMichal Terepeta2016-10-266-81/+59
| | | | | | | | | | | | | | | | | | | | This commit: - Moves the remaining few methods concerned with dataflow analysis from `CmmUtils` to `Hoopl.Dataflow`. - Refactors the code to not use `FwdPass` and simply pass `FwdTransfer` and `DataflowLattice` directly. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2634
* cmm/Hoopl/Dataflow: minor cleanupMichal Terepeta2016-10-221-26/+40
| | | | | | | | | | | | | | | | | This doesn't have any functional changes, it simply removes one unnecessary top binding and improves the comments. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2619
* cmm/Hoopl/Dataflow: remove unused codeMichal Terepeta2016-10-183-665/+11
| | | | | | | | | | | | | | | | | | | | We had *a lot* of code copied from Hoopl that is for rewriting. But GHC doesn't use it (it only uses some forked Hoopl code for analysis). So we can safely kill all this code and make it much easier to refactor and improve the parts that we do use. Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2612
* Turn divInt# and modInt# into bitwise operations when possibleTakano Akio2016-09-051-20/+1
| | | | | | | | | | | | | | | | | | | This implements #5615 for divInt# and modInt#. I also included rules to do constant-folding when the both arguments are known. Test Plan: validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D2486 GHC Trac Issues: #5615
* Remove StgRubbishArg and CmmArgÖmer Sinan Ağacan2016-08-107-77/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea behind adding special "rubbish" arguments was in unboxed sum types depending on the tag some arguments are not used and we don't want to move some special values (like 0 for literals and some special pointer for boxed slots) for those arguments (to stack locations or registers). "StgRubbishArg" was an indicator to the code generator that the value won't be used. During Stg-to-Cmm we were then not generating any move or store instructions at all. This caused problems in the register allocator because some variables were only initialized in some code paths. As an example, suppose we have this STG: (after unarise) Lib.$WT = \r [dt_sit] case case dt_sit of { Lib.F dt_siv [Occ=Once] -> (#,,#) [1# dt_siv StgRubbishArg::GHC.Prim.Int#]; Lib.I dt_siw [Occ=Once] -> (#,,#) [2# StgRubbishArg::GHC.Types.Any dt_siw]; } of dt_six { (#,,#) us_giC us_giD us_giE -> Lib.T [us_giC us_giD us_giE]; }; This basically unpacks a sum type to an unboxed sum with 3 fields, and then moves the unboxed sum to a constructor (`Lib.T`). This is the Cmm for the inner case expression (case expression in the scrutinee position of the outer case): ciN: ... -- look at dt_sit's tag if (_ciT::P64 != 1) goto ciS; else goto ciR; ciS: -- Tag is 2, i.e. Lib.F _siw::I64 = I64[_siu::P64 + 6]; _giE::I64 = _siw::I64; _giD::P64 = stg_RUBBISH_ENTRY_info; _giC::I64 = 2; goto ciU; ciR: -- Tag is 1, i.e. Lib.I _siv::P64 = P64[_siu::P64 + 7]; _giD::P64 = _siv::P64; _giC::I64 = 1; goto ciU; Here one of the blocks `ciS` and `ciR` is executed and then the execution continues to `ciR`, but only `ciS` initializes `_giE`, in the other branch `_giE` is not initialized, because it's "rubbish" in the STG and so we don't generate an assignment during code generator. The code generator then panics during the register allocations: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160722 for x86_64-unknown-linux): LocalReg's live-in to graph ciY {_giE::I64} (`_giD` is also "rubbish" in `ciS`, but it's still initialized because it's a pointer slot, we have to initialize it otherwise garbage collector follows the pointer to some random place. So we only remove assignment if the "rubbish" arg has unboxed type.) This patch removes `StgRubbishArg` and `CmmArg`. We now always initialize rubbish slots. If the slot is for boxed types we use the existing `absentError`, otherwise we initialize the slot with literal 0. Reviewers: simonpj, erikd, austin, simonmar, bgamari Reviewed By: erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2446
* RegAlloc: Use IntSet/IntMaps instead of generic Set/MapsÖmer Sinan Ağacan2016-08-061-1/+7
|
* CmmLayoutStack: Minor simplificationÖmer Sinan Ağacan2016-08-041-2/+2
|
* CmmLive: Remove some redundant exportsÖmer Sinan Ağacan2016-08-041-1/+1
|
* Use MO_Cmpxchg in Primops.cmm instead of ccall cas(..)alexbiehl2016-08-011-1/+6
| | | | | | | | | | | | | | | | | Adjust `CmmParse.y` to parse the `cmpxchg{8, 16, 32, 64}` instructions and use the 32 respectively the 64 bit variant in `Primops.cmm`. This effectively eliminates the compare-and-swap ccall to the rts. Based off the mailing list question from @osa1 (https://mail.haskell.org/pipermail/ghc-devs/2016-July/012506.html). Reviewers: simonmar, austin, erikd, bgamari, trommler Reviewed By: erikd, bgamari, trommler Subscribers: carter, trommler, osa1, thomie Differential Revision: https://phabricator.haskell.org/D2431
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-218-37/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
* CodeGen: Way to dump cmm only once (#11717)Vladimir Trubilov2016-07-172-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | | The `-ddump-cmm` put all stages of Cmm processing into one output. This patch changes its behavior and adds two more options to make Cmm dumping flexible. - `-ddump-cmm-from-stg` dumps only initial version of Cmm right after STG->Cmm codegen - `-ddump-cmm` dumps the final result of the Cmm pipeline processing - `-ddump-cmm-verbose` dumps intermediate output of each Cmm pipeline step - `-ddump-cmm-proc` and `-ddump-cmm-caf` seems were lost. Now enabled Test Plan: ./validate Reviewers: thomie, simonmar, austin, bgamari Reviewed By: thomie, simonmar Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2393 GHC Trac Issues: #11717
* Document some codegen nondeterminismBartosz Nitka2016-07-072-5/+10
| | | | | | | | | Bit-for-bit reproducible binaries are not a goal for now, so this is just marking places that could be a problem. Doing this will allow eltsUFM to be removed and will leave only nonDetEltsUFM. GHC Trac: #4012
* CmmExpr: remove unused `vgcFlag` functionMichal Terepeta2016-06-301-6/+1
| | | | | | | | | | | | Test Plan: validate Reviewers: austin, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2351
* Delete Ord UniqueBartosz Nitka2016-06-304-12/+110
| | | | | | | | | | | | | | | | | | | | | | Ord Unique can be a source of invisible, accidental nondeterminism as explained in Note [No Ord for Unique]. This removes it, leaving a note with rationale. It's unfortunate that I had to write Ord instances for codegen data structures by hand, but I believe that it's a right trade-off here. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2370 GHC Trac Issues: #4012
* Provide Uniquable version of SCCBartosz Nitka2016-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want to remove the `Ord Unique` instance because there's no way to implement it in deterministic way and it's too easy to use by accident. We sometimes compute SCC for datatypes whose Ord instance is implemented in terms of Unique. The Ord constraint on SCC is just an artifact of some internal data structures. We can have an alternative implementation with a data structure that uses Uniquable instead. This does exactly that and I'm pleased that I didn't have to introduce any duplication to do that. Test Plan: ./validate I looked at performance tests and it's a tiny bit better. Reviewers: bgamari, simonmar, ezyang, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2359 GHC Trac Issues: #4012
* CmmNode: Make CmmTickScope's Unique strictBen Gamari2016-06-181-1/+1
| | | | | There is no reason why we need laziness here and making it strict enables unpacking.
* Fix Ticky histogram on WindowsTamar Christina2016-06-091-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The histogram types are defined in `Ticky.c` as `StgInt` values. ``` EXTERN StgInt RET_NEW_hst[TICKY_BIN_COUNT] INIT({0}); EXTERN StgInt RET_OLD_hst[TICKY_BIN_COUNT] INIT({0}); EXTERN StgInt RET_UNBOXED_TUP_hst[TICKY_BIN_COUNT] INIT({0}); ``` which means they'll be `32-bits` on `x86` and `64-bits` on `x86_64`. However the `bumpHistogram` in `StgCmmTicky` is incrementing them as if they're a `cLong`. A long on Windows `x86_64` is `32-bit`. As such when then value for the `_hst_1` is being set what it's actually doing is setting the value of the high bits of the first entry. This ends up giving us `0b‭100000000000000000000000000000000‬` or `4294967296` as is displayed in the ticket on #8308. Since `StgInt` is defined using the `WORD` size. Just use that directly in `bumpHistogram`. Also since `cLong` is no longer used after this commit it will also be dropped. Test Plan: make TEST=T8308 Reviewers: mlen, jstolarek, bgamari, thomie, goldfire, simonmar, austin Reviewed By: bgamari, thomie Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2318 GHC Trac Issues: #8308
* Kill two instances of uniqSetToListBartosz Nitka2016-06-071-1/+2
| | | | | | | There should be no performance impact of switching to the deterministic set here. GHC Trac: #4012
* Update a Cmm noteÖmer Sinan Ağacan2016-05-311-0/+1
|
* CLabel: Catch #11155 during C-- pretty-printingBen Gamari2016-05-181-4/+17
| | | | | | | | | | | | | | | | | | | | | In #11555 we ended up generating references to the non-existence stg_ap_0_upd. Here we add asserts to verify that we don't generate references to non-existent selector or application symbols. It would likely also make sense to add further asserts during code generation, so we can catch the issue even closer to its source. Test Plan: Validate Reviewers: simonmar, austin, ezyang Reviewed By: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2230 GHC Trac Issues: #11155
* Rework parser to allow use with DynFlagsDave Laing2016-05-183-40/+102
| | | | | | | | | | | | | | | | | Split out the options needed by the parser from DynFlags, making the parser more friendly to standalone usage. Test Plan: validate Reviewers: simonmar, alanz, bgamari, austin, thomie Reviewed By: simonmar, alanz, bgamari, thomie Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2208 GHC Trac Issues: #10961
* Warn about simplifiable class constraintsSimon Peyton Jones2016-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provoked by Trac #11948, this patch adds a new warning to GHC -Wsimplifiable-class-constraints It warns if you write a class constraint in a type signature that can be simplified by an existing instance declaration. Almost always this means you should simplify it right now; type inference is very fragile without it, as #11948 shows. I've put the warning as on-by-default, but I suppose that if there are howls of protest we can move it out (as happened for -Wredundant-constraints. It actually found an example of an over-complicated context in CmmNode. Quite a few tests use these weird contexts to trigger something else, so I had to suppress the warning in those. The 'haskeline' library has a few occurrences of the warning (which I think should be fixed), so I switched it off for that library in warnings.mk. The warning itself is done in TcValidity.check_class_pred. HOWEVER, when type inference fails we get a type error; and the error suppresses the (informative) warning. So as things stand, the warning only happens when it doesn't cause a problem. Not sure what to do about this, but this patch takes us forward, I think.
* Reduce default for -fmax-pmcheck-iterations from 1e7 to 2e6Herbert Valerio Riedel2016-04-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | The commit 28f951edfe50ea5182065144340061ec326781f5 introduced the `-fmax-pmcheck-iterations` flag and set the default limit to 1e7 iterations. However, this value is still high enough that it can result GHC to exhibit memory spikes beyond 1 GiB of RAM usage (heap profile showed several `(:)`s, as well as `THUNK_2_0`, and `PmCon` during the memory spikes) A value of 2e6 seems to be a safer upper bound which still manages to let the checker not run into the limit in most cases. Test Plan: Validate, try building a few Hackage packages Reviewers: austin, gkaracha, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2095
* Add NCG support for AIX/ppc32Herbert Valerio Riedel2016-03-241-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This extends the previous work to revive the unregisterised GHC build for AIX/ppc32. Strictly speaking, AIX runs on POWER4 (and later) hardware, but the PPC32 instructions implemented in the PPC NCG represent a compatible subset of the POWER4 ISA. IBM AIX follows the PowerOpen ABI (and shares many similiarites with the Linux PPC64 ELF V1 NCG backend) but uses the rather limited XCOFF format (compared to ELF). This doesn't support dynamic libraries yet. A major limiting factor is that the AIX assembler does not support the `@ha`/`@l` relocation types nor the ha16()/lo16() functions Darwin's assembler supports. Therefore we need to avoid emitting those. In case of numeric literals we simply compute the functions ourselves, while for labels we have to use local TOCs and hope everything fits into a 16bit offset (for ppc32 this gives us at most 16384 entries per TOC section, which is enough to compile GHC). Another issue is that XCOFF doesn't seem to have a relocation type for label-differences, and therefore the label-differences placed into tables-next-to-code can't be relocated, but the linker may rearrange different sections, so we need to place all read-only sections into the same `.text[PR]` section to workaround this. Finally, the PowerOpen ABI distinguishes between function-descriptors and actualy entry-point addresses. For AIX we need to be specific when emitting assembler code whether we want the address of the function descriptor `printf`) or for the entry-point (`.printf`). So we let the asm pretty-printer prefix a dot to all emitted subroutine calls (i.e. `BL`) on AIX only. For now, STG routines' entry-point labels are not prefixed by a label and don't have any associated function-descriptor. Reviewers: austin, trommler, erikd, bgamari Reviewed By: trommler, erikd, bgamari Differential Revision: https://phabricator.haskell.org/D2019
* ErrUtils: Add timings to compiler phasesBen Gamari2016-03-241-2/+1
| | | | | | | | | | | | | | | | | | | | | | | This adds timings and allocation figures to the compiler's output when run with `-v2` in an effort to ease performance analysis. Todo: * Documentation * Where else should we add these? * Perhaps we should remove some of the now-arguably-redundant `showPass` occurrences where they are * Must we force more? * Perhaps we should place this behind a `-ftimings` instead of `-v2` Test Plan: `ghc -v2 Test.hs`, look at the output Reviewers: hvr, goldfire, simonmar, austin Reviewed By: simonmar Subscribers: angerman, michalt, niteria, ezyang, thomie Differential Revision: https://phabricator.haskell.org/D1959
* Dwarf: Add support for labels in unwind expressionsBen Gamari2016-03-201-0/+3
| | | | | | | | | | | | Test Plan: Look at DWARF output. Reviewers: scpmw, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1734
* fix Float/Double unreg cross-compilationSergei Trofimovich2016-03-101-30/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Looking at more failures on m68k (Trac #11395) I've noticed the arith001 and arith012 test failures. (--host=x86_64-linux --target=m68k-linux). The following example was enough to reproduce a problem: v :: Float v = 43 main = print v m68k binaries printed '0.0' instead of '43.0'. The bug here is how we encode Floats and Double as Words with the same binary representation. Floats: Before the patch we just coerced Float to Int. That breaks when we cross-compile from 64-bit LE to 32-bit BE. The patch fixes conversion by accounting for padding. when we extend 32-bit value to 64-bit value (LE and BE do it slightly differently). Doubles: Before the patch Doubles were coerced to a pair of Ints (not correct as x86_64 can hold Double in one Int) and then trucated this pair of Ints to pair of Word32. The patch fixes conversion by always decomposing in Word32 and accounting for host endianness (newly introduced hostBE) and target endianness (wORDS_BIGENDIAN). I've tested this patch on Double and Float conversion on --host=x86_64-linux --target=m68k-linux crosscompiler. It fixes 10 tests related to printing Floats and Doubles. Thanks to Bertram Felgenhauer who poined out this probem. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: checked some examples manually, fixed 10 tests in test suite Reviewers: int-e, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1990 GHC Trac Issues: #11395
* Split external symbol prototypes (EF_) (Trac #11395)Sergei Trofimovich2016-03-082-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before the patch both Cmm and C symbols were declared with 'EF_' macro: #define EF_(f) extern StgFunPtr f() but for Cmm symbols we know exact prototypes. The patch splits there prototypes in to: #define EFF_(f) void f() /* See Note [External function prototypes] */ #define EF_(f) StgFunPtr f(void) Cmm functions are 'EF_' (External Functions), C functions are 'EFF_' (External Foreign Functions). While at it changed external C function prototype to return 'void' to workaround ghc bug on m68k. Described in detail in Trac #11395. This makes simple tests work on m68k-linux target! Thanks to Michael Karcher for awesome analysis happening in Trac #11395. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: ran "hello world" on m68k successfully Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1975 GHC Trac Issues: #11395
* Fix minimum alignment for StgClosure (Trac #11395)Sergei Trofimovich2016-03-061-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug is observed on m68k-linux target as crash in RTS: -- a.hs: main = print 43 $ inplace/bin/ghc-stage1 --make -debug a.hs $ ./a Program terminated with signal SIGSEGV, Segmentation fault. #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 (gdb) bt #0 0x80463b0a in LOOKS_LIKE_INFO_PTR_NOT_NULL (p=32858) at includes/rts/storage/ClosureMacros.h:248 #1 0x80463b46 in LOOKS_LIKE_INFO_PTR (p=32858) at includes/rts/storage/ClosureMacros.h:253 #2 0x80463b6c in LOOKS_LIKE_CLOSURE_PTR ( p=0x805aac6e <stg_dummy_ret_closure>) at includes/rts/storage/ClosureMacros.h:258 #3 0x80463e4c in initStorage () at rts/sm/Storage.c:121 #4 0x8043ffb4 in hs_init_ghc (...) at rts/RtsStartup.c:181 #5 0x80455982 in hs_main (...) at rts/RtsMain.c:51 #6 0x80003c1c in main () GHC assumes last 2 pointer bits are tags on 32-bit targets. But here 'stg_dummy_ret_closure' address violates the assumption: LOOKS_LIKE_CLOSURE_PTR (p=0x805aac6e <stg_dummy_ret_closure>) I've added compiler hint for static StgClosure objects to align closures at least by their natural alignment (what GHC assumes). See Note [StgWord alignment]. Signed-off-by: Sergei Trofimovich <siarheit@google.com> Test Plan: ran basic test on m68k qemu, it got past ASSERTs Reviewers: simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1974 GHC Trac Issues: #11395
* Fix the removal of unnecessary stack checksJonas Scholl2016-02-091-6/+21
| | | | | | | | | | | | | | | | | | | | The module CmmLayoutStack removes stack checks if a function does not use stack space. However, it can only recognize checks of the form Sp < SpLim. However, these checks get sometimes rewritten to Sp >= SpLim (with both branches swapped), so we better recognize these checks too. Test Plan: ./validate Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1881 GHC Trac Issues: #11533
* Improve comments in CmmSwitchJoachim Breitner2016-01-211-17/+22
| | | | | | | addressing some valuable feedback by thomie at https://phabricator.haskell.org/rGHCde1160be0477 Differential Revision: https://phabricator.haskell.org/D1816
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-189-273/+271
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* StgCmmForeign: Push local register creation into code generationBen Gamari2016-01-051-10/+5
| | | | | | | | | | | | | | | | | | | | | | | The interfaces to {save,load}ThreadState were quite messy due to the need to pass in local registers (produced with draws from a unique supply) since they were used from both FCode and UniqSM. This, however, is entirely unnecessary as we already have an abstraction to capture this effect: MonadUnique. Use it. This is part of an effort to properly represent stack unwinding information for foreign calls. Test Plan: validate Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1733
* Remove some redundant definitions/constraintsHerbert Valerio Riedel2015-12-312-2/+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-313-10/+1
| | | | | | | | | | | | 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
* Random typo fixesHerbert Valerio Riedel2015-12-171-1/+1
| | | | [skip ci]
* DynFlags: remove Opt_StaticThomas Miedema2015-12-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | There are currently 2 different ways to test for a static or dynamic build: * Test if WayDyn is in ways * Test if Opt_Static is set The problem is that these can easily go out of sync, especially when using the GHC API. This commit replaces all queries of Opt_Static with an equivalent query of WayDyn. This would have prevented bug #8294 and fixes #11154. Reviewers: hvr, austin, bgamari Reviewed By: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1607 GHC Trac Issues: #10636
* Add kind equalities to GHC.Richard Eisenberg2015-12-114-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* Kill redundant patternsBen Gamari2015-12-031-5/+0
| | | | | George's new exhaustiveness checker now realizes these are impossible. Yay!
View Lorry Controller Status