summaryrefslogtreecommitdiff
path: root/ghc/compiler/nativeGen/AsmCodeGen.lhs
Commit message (Collapse)AuthorAgeFilesLines
* Reorganisation of the source treeSimon Marlow2006-04-071-545/+0
| | | | | | | | | | | | | | | Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
* NCG: Handle loops in register allocatorwolfgang.thaller@gmx.net2006-02-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fill in the missing parts in the register allocator so that it can handle loops. *) The register allocator now runs in the UniqSuppy monad, as it needs to be able to generate unique labels for fixup code blocks. *) A few functions have been added to RegAllocInfo: mkRegRegMoveInstr -- generates a good old move instruction mkBranchInstr -- used to be MachCodeGen.genBranch patchJump -- Change the destination of a jump *) The register allocator now makes sure that only one spill slot is used for each temporary, even if it is spilled and reloaded several times. This obviates the need for memory-to-memory moves in fixup code. LIMITATIONS: *) The case where the fixup code needs to cyclically permute a group of registers is currently unhandled. This will need more work once we come accross code where this actually happens. *) Register allocation for code with loop is probably very inefficient (both at compile-time and at run-time). *) We still cannot compile the RTS via NCG, for various other reasons.
* extract some of the generic C-- optimisations from the NCGSimon Marlow2006-02-241-382/+2
|
* [project @ 2005-08-02 14:04:19 by simonmar]simonmar2005-08-021-1/+7
| | | | save + restore caller-saves registers around foreign calls
* [project @ 2005-07-28 11:19:03 by simonmar]simonmar2005-07-281-3/+6
| | | | | Fix a bad space leak in the native code generator: turn a couple of lazy tuple matches into strict matches.
* [project @ 2005-05-03 10:29:19 by simonmar]simonmar2005-05-031-5/+13
| | | | MO_S_Conv folding: fold floating-point literals properly
* [project @ 2005-04-11 08:52:47 by simonmar]simonmar2005-04-111-0/+3
| | | | Add a Todo
* [project @ 2005-04-01 12:14:29 by simonmar]simonmar2005-04-011-6/+31
| | | | | | | | | | | | | | | | First cut at the x86_64 native code generator. Lots of code is shared with i386, but floating point uses SSE2. This more or less works, the things I know that don't work are: - the floating-point primitives (sin, cos etc.) are missing - floating-point comparisons involving NaN are wrong - there's no PIC support yet Also, I have a long list of small things to fix up to improve performance. I think the small memory model is assumed, for now.
* [project @ 2005-03-21 10:50:22 by simonmar]simonmar2005-03-211-3/+3
| | | | | | | | | | | | Complete the transition of -split-objs into a dynamic flag (looks like I half-finished it in the last commit). Also: complete the transition of -tmpdir into a dynamic flag, which involves some rearrangement of code from SysTools into DynFlags. Someday, initSysTools should move wholesale into initDynFlags, because most of the state that it initialises is now part of the DynFlags structure, and the rest could be moved in easily.
* [project @ 2005-03-18 13:37:27 by simonmar]simonmar2005-03-181-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Flags cleanup. Basically the purpose of this commit is to move more of the compiler's global state into DynFlags, which is moving in the direction we need to go for the GHC API which can have multiple active sessions supported by a single GHC instance. Before: $ grep 'global_var' */*hs | wc -l 78 After: $ grep 'global_var' */*hs | wc -l 27 Well, it's an improvement. Most of what's left won't really affect our ability to host multiple sessions. Lots of static flags have become dynamic flags (yay!). Notably lots of flags that we used to think of as "driver" flags, like -I and -L, are now dynamic. The most notable static flags left behind are the "way" flags, eg. -prof. It would be nice to fix this, but it isn't urgent. On the way, lots of cleanup has happened. Everything related to static and dynamic flags lives in StaticFlags and DynFlags respectively, and they share a common command-line parser library in CmdLineParser. The flags related to modes (--makde, --interactive etc.) are now private to the front end: in fact private to Main itself, for now.
* [project @ 2005-01-23 06:10:15 by wolfgang]wolfgang2005-01-231-1/+8
| | | | | | | | | | | | | | | | | | | | | | | Add support for the dead code stripping feature of recent Apple linkers. If your code is compiled using the NCG, you can now specify -optl-W,-dead_strip on the GHC command line when linking. It will have basically the same effect as using split-objs to build the libraries. Advantages over split-objs: * No evil perl script involved * Requires no special handling when building libraries Disadvantages: * The current version of Apple's linker is slow when given the -dead_strip flag. _REALLY_ slow. * Mac OS X only. This works by making the NCG emit the .subsections_via_symbols directive. Additionally, we have to add an extra label at the top of every info table, and make sure that the entry code references it (otherwise the info table will be considered part of the preceding entry code). The mangler just removes the .subsections_via_symbols directive.
* [project @ 2005-01-16 05:31:39 by wolfgang]wolfgang2005-01-161-6/+0
| | | | | | | | | | | | A first stab at position independent code generation for i386-linux. It doesn't work yet, but it shouldn't break anything. What we need now is one or both of the following: a) A volunteer to implement PIC for x86 -fvia-C (I definitely refuse to touch any piece of code that contains both Perl and x86 assembly). b) A volunteer to improve the NCG to the point where it can compile the RTS (so we won't need point a).
* [project @ 2005-01-13 16:32:34 by simonmar]simonmar2005-01-131-0/+3
| | | | Small optimisation: allow lookForInline to skip over CmmNop too
* [project @ 2004-10-07 15:54:03 by wolfgang]wolfgang2004-10-071-68/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Position Independent Code and Dynamic Linking Support, Part 1 This commit allows generation of position independent code (PIC) that fully supports dynamic linking on Mac OS X and PowerPC Linux. Other platforms are not yet supported, and there is no support for actually linking or using dynamic libraries - so if you use the -fPIC or -dynamic code generation flags, you have to type your (platform-specific) linker command lines yourself. nativeGen/PositionIndependentCode.hs: New file. Look here for some more comments on how this works. cmm/CLabel.hs: Add support for DynamicLinkerLabels and PIC base labels - for use inside the NCG. needsCDecl: Case alternative labels now need C decls, see the codeGen/CgInfoTbls.hs below for details cmm/Cmm.hs: Add CmmPicBaseReg (used in NCG), and CmmLabelDiffOff (used in NCG and for offsets in info tables) cmm/CmmParse.y: support offsets in info tables cmm/PprC.hs: support CmmLabelDiffOff Case alternative labels now need C decls (see the codeGen/CgInfoTbls.hs for details), so we need to pprDataExterns for info tables. cmm/PprCmm.hs: support CmmLabelDiffOff codeGen/CgInfoTbls.hs: no longer store absolute addresses in info tables, instead, we store offsets. Also, for vectored return points, emit the alternatives _after_ the vector table. This is to work around a limitation in Apple's as, which refuses to handle label differences where one label is at the end of a section. Emitting alternatives after vector info tables makes sure this never happens in GHC generated code. Case alternatives now require prototypes in hc code, though (see changes in PprC.hs, CLabel.hs). main/CmdLineOpts.lhs: Add a new option, -fPIC. main/DriverFlags.hs: Pass the correct options for PIC to gcc, depending on the platform. Only for powerpc for now. nativeGen/AsmCodeGen.hs: Many changes... Mac OS X-specific management of import stubs is no longer, it's now part of a general mechanism to handle such things for all platforms that need it (Darwin [both ppc and x86], Linux on ppc, and some platforms we don't support). Move cmmToCmm into its own monad which can accumulate a list of imported symbols. Make it call cmmMakeDynamicReference at the right places. nativeGen/MachCodeGen.hs: nativeGen/MachInstrs.hs: nativeGen/MachRegs.lhs: nativeGen/PprMach.hs: nativeGen/RegAllocInfo.hs: Too many changes to enumerate here, PowerPC specific. nativeGen/NCGMonad.hs: NatM still tracks imported symbols, as more labels can be created during code generation (float literals, jump tables; on some platforms all data access has to go through the dynamic linking mechanism). driver/mangler/ghc-asm.lprl: Mangle absolute addresses in info tables to offsets. Correctly pass through GCC-generated PIC for Mac OS X and powerpc linux. includes/Cmm.h: includes/InfoTables.h: includes/Storage.h: includes/mkDerivedConstants.c: rts/GC.c: rts/GCCompact.c: rts/HeapStackCheck.cmm: rts/Printer.c: rts/RetainerProfile.c: rts/Sanity.c: Adapt to the fact that info tables now contain offsets. rts/Linker.c: Mac-specific: change machoInitSymbolsWithoutUnderscore to support PIC.
* [project @ 2004-08-23 10:11:23 by simonmar]simonmar2004-08-231-12/+12
| | | | | Fix an infinite loop in the cmm-optimiser in the native codegen, and refactor: move isAssociativeMachOp into MachOp.
* [project @ 2004-08-13 13:04:50 by simonmar]simonmar2004-08-131-326/+729
| | | | Merge backend-hacking-branch onto HEAD. Yay!
* [project @ 2003-06-02 13:27:33 by simonpj]simonpj2003-06-021-0/+2
| | | | Prune imports
* [project @ 2003-02-11 11:53:51 by wolfgang]wolfgang2003-02-111-10/+25
| | | | | | | | | | Mac OS X: Add support for dynamic linker "symbol stubs". For every function that might be imported from a dynamic library, we have to generate a short piece of assembly code. Extend the NatM monad to keep track of the list of imports (for which stubs will be generated later). Fix a bug concerning 64 bit ints (hi and low words were swapped in one place).
* [project @ 2002-12-11 15:36:20 by simonmar]simonmar2002-12-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge the eval-apply-branch on to the HEAD ------------------------------------------ This is a change to GHC's evaluation model in order to ultimately make GHC more portable and to reduce complexity in some areas. At some point we'll update the commentary to describe the new state of the RTS. Pending that, the highlights of this change are: - No more Su. The Su register is gone, update frames are one word smaller. - Slow-entry points and arg checks are gone. Unknown function calls are handled by automatically-generated RTS entry points (AutoApply.hc, generated by the program in utils/genapply). - The stack layout is stricter: there are no "pending arguments" on the stack any more, the stack is always strictly a sequence of stack frames. This means that there's no need for LOOKS_LIKE_GHC_INFO() or LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know how to find the boundary between the text and data segments (BIG WIN!). - A couple of nasty hacks in the mangler caused by the neet to identify closure ptrs vs. info tables have gone away. - Info tables are a bit more complicated. See InfoTables.h for the details. - As a side effect, GHCi can now deal with polymorphic seq. Some bugs in GHCi which affected primitives and unboxed tuples are now fixed. - Binary sizes are reduced by about 7% on x86. Performance is roughly similar, some programs get faster while some get slower. I've seen GHCi perform worse on some examples, but haven't investigated further yet (GHCi performance *should* be about the same or better in theory). - Internally the code generator is rather better organised. I've moved info-table generation from the NCG into the main codeGen where it is shared with the C back-end; info tables are now emitted as arrays of words in both back-ends. The NCG is one step closer to being able to support profiling. This has all been fairly thoroughly tested, but no doubt I've messed up the commit in some way.
* [project @ 2002-09-13 15:02:25 by simonpj]simonpj2002-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -------------------------------------- Make Template Haskell into the HEAD -------------------------------------- This massive commit transfers to the HEAD all the stuff that Simon and Tim have been doing on Template Haskell. The meta-haskell-branch is no more! WARNING: make sure that you * Update your links if you are using link trees. Some modules have been added, some have gone away. * Do 'make clean' in all library trees. The interface file format has changed, and you can get strange panics (sadly) if GHC tries to read old interface files: e.g. ghc-5.05: panic! (the `impossible' happened, GHC version 5.05): Binary.get(TyClDecl): ForeignType * You need to recompile the rts too; Linker.c has changed However the libraries are almost unaltered; just a tiny change in Base, and to the exports in Prelude. NOTE: so far as TH itself is concerned, expression splices work fine, but declaration splices are not complete. --------------- The main change --------------- The main structural change: renaming and typechecking have to be interleaved, because we can't rename stuff after a declaration splice until after we've typechecked the stuff before (and the splice itself). * Combine the renamer and typecheker monads into one (TcRnMonad, TcRnTypes) These two replace TcMonad and RnMonad * Give them a single 'driver' (TcRnDriver). This driver replaces TcModule.lhs and Rename.lhs * The haskell-src library package has a module Language/Haskell/THSyntax which defines the Haskell data type seen by the TH programmer. * New modules: hsSyn/Convert.hs converts THSyntax -> HsSyn deSugar/DsMeta.hs converts HsSyn -> THSyntax * New module typecheck/TcSplice type-checks Template Haskell splices. ------------- Linking stuff ------------- * ByteCodeLink has been split into ByteCodeLink (which links) ByteCodeAsm (which assembles) * New module ghci/ObjLink is the object-code linker. * compMan/CmLink is removed entirely (was out of place) Ditto CmTypes (which was tiny) * Linker.c initialises the linker when it is first used (no need to call initLinker any more). Template Haskell makes it harder to know when and whether to initialise the linker. ------------------------------------- Gathering the LIE in the type checker ------------------------------------- * Instead of explicitly gathering constraints in the LIE tcExpr :: RenamedExpr -> TcM (TypecheckedExpr, LIE) we now dump the constraints into a mutable varabiable carried by the monad, so we get tcExpr :: RenamedExpr -> TcM TypecheckedExpr Much less clutter in the code, and more efficient too. (Originally suggested by Mark Shields.) ----------------- Remove "SysNames" ----------------- Because the renamer and the type checker were entirely separate, we had to carry some rather tiresome implicit binders (or "SysNames") along inside some of the HsDecl data structures. They were both tiresome and fragile. Now that the typechecker and renamer are more intimately coupled, we can eliminate SysNames (well, mostly... default methods still carry something similar). ------------- Clean up HsPat ------------- One big clean up is this: instead of having two HsPat types (InPat and OutPat), they are now combined into one. This is more consistent with the way that HsExpr etc is handled; there are some 'Out' constructors for the type checker output. So: HsPat.InPat --> HsPat.Pat HsPat.OutPat --> HsPat.Pat No 'pat' type parameter in HsExpr, HsBinds, etc Constructor patterns are nicer now: they use HsPat.HsConDetails for the three cases of constructor patterns: prefix, infix, and record-bindings The *same* data type HsConDetails is used in the type declaration of the data type (HsDecls.TyData) Lots of associated clean-up operations here and there. Less code. Everything is wonderful.
* [project @ 2002-08-29 15:44:11 by simonmar]simonmar2002-08-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Housekeeping: - The main goal is to remove dependencies on hslibs for a bootstrapped compiler, leaving only a requirement that the packages base, haskell98 and readline are built in stage 1 in order to bootstrap. We're almost there: Posix is still required for signal handling, but all other dependencies on hslibs are now gone. Uses of Addr and ByteArray/MutableByteArray array are all gone from the compiler. PrimPacked defines the Ptr type for GHC 4.08 (which didn't have it), and it defines simple BA and MBA types to replace uses of ByteArray and MutableByteArray respectively. - Clean up import lists. HsVersions.h now defines macros for some modules which have moved between GHC versions. eg. one now imports 'GLAEXTS' to get at unboxed types and primops in the compiler. Many import lists have been sorted as per the recommendations in the new style guidelines in the commentary. I've built the compiler with GHC 4.08.2, 5.00.2, 5.02.3, 5.04 and itself, and everything still works here. Doubtless I've got something wrong, though.
* [project @ 2002-04-29 14:03:38 by simonmar]simonmar2002-04-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | FastString cleanup, stage 1. The FastString type is no longer a mixture of hashed strings and literal strings, it contains hashed strings only with O(1) comparison (except for UnicodeStr, but that will also go away in due course). To create a literal instance of FastString, use FSLIT(".."). By far the most common use of the old literal version of FastString was in the pattern ptext SLIT("...") this combination still works, although it doesn't go via FastString any more. The next stage will be to remove the need to use this special combination at all, using a RULE. To convert a FastString into an SDoc, now use 'ftext' instead of 'ptext'. I've also removed all the FAST_STRING related macros from HsVersions.h except for SLIT and FSLIT, just use the relevant functions from FastString instead.
* [project @ 2002-01-08 10:59:42 by sewardj]sewardj2002-01-081-10/+19
| | | | | | | | | | merge from stable branch: 1.46.4.3 +14 -7 fptools/ghc/compiler/nativeGen/AsmCodeGen.lhs 1.47.4.3 +2 -0 fptools/ghc/compiler/nativeGen/MachMisc.lhs Treat literal appearances of BaseReg in Stix trees uniformly. This is now taken to mean the &MainCapability.r, regardless of whether BaseReg is in a register (x86) or synthesised (sparc).
* [project @ 2001-12-20 15:16:13 by sewardj]sewardj2001-12-201-1/+1
| | | | nano-comment-wibble
* [project @ 2001-12-14 15:26:14 by sewardj]sewardj2001-12-141-2/+0
| | | | | | | | | | | | | | | | | | | | | | Get rid of multiple-result MachOps (MO_NatS_AddC, MO_NatS_SubC, MO_NatS_MulC) which implement {add,sub,mul}IntC#. Supporting gunk in the NCG disappears as a result. Instead: * {add,sub}IntC# are translated out during abstract C simplification, turning into the xor-xor-invert-and-shift sequence previously defined in PrimOps.h. * mulIntC# is more difficult to get rid of portably. Instead we have a new single-result PrimOp, mulIntMayOflo, with corresponding MachOp MO_NatS_MulMayOflo. This tells you whether a W x W -> W signed multiply might overflow, where W is the word size. When W=32, is implemented by computing a 2W-long result. When W=64, we use the previous approximation. PrelNum.lhs' implementation of timesInteger changes slightly, to use the new PrimOp.
* [project @ 2001-12-12 18:12:45 by sewardj]sewardj2001-12-121-1/+2
| | | | | | | | | | | | | | | | | | Make the sparc native code generator work again after recent primop hackery. * Track the change from PrimOp to MachOp at the Stix level. * Teach the sparc insn selector how to generate 64-bit code. * Fix various bogons in sparc {Int,Double,Float} <-> {Int,Double,Float} conversions which only happened to generate correct code by accident, so far. * Synthesise BaseReg from &MainCapability.r on archs which do not have BaseReg in a regiser (eg sparc :) At the moment {add,sub,mul}Int# are not implemented. To be fixed.
* [project @ 2001-12-10 18:04:51 by sewardj]sewardj2001-12-101-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add just enough infrastructure to the NCG that it can deal with simple 64-bit code on 32-bit platforms. Main changes are: * Addition of a simple 64-bit instruction selection fn iselExpr64 to MachCode. This generates code for a 64-bit value and places the results into two virtual registers, related thusly: * Add a new type VRegUnique, which is used to label Stix virtual registers. This type used to be a plain Unique, but that forces the assumption that each Abstract-C level C temporary corresponds to exactly one Stix virtual register, which is untrue when the C temporary is 64-bit sized on a 32-bit machine. In the new scheme, the Unique for the C temporary can turn into two related VRegUniques, related by having the same embedded unique. * Made a start on 'target metrics' by adding ncg_target_is_32bits to the end of Stix.lhs. * Cleaned up numerous other gruesomenesses in the NCG which never came to light before now. Got rid of MachMisc.sizeOf, which doesn't make sense in a 64-bit setting, and replaced it by calls to PrimRep.getPrimRepArrayElemSize, which, as far as I'm concerned, is the definitive answer to the questio `How Big Is This PrimRep Really?' Result: on x86-linux, at least, you can now compile the Entire Prelude with -fasm! At this stage I cannot claim that the resulting code is correct, but it's a start.
* [project @ 2001-12-06 11:50:07 by sewardj]sewardj2001-12-061-0/+5
| | | | | | | Add constructor CBytesPerWord to (the wildly-misnamed) CAddrMode, and use this in various places to remove word size dependencies in the C -> C simplification pass. Tart up the Stix constant folder a bit so as to be able to fold out the shift/mask literal expressions.
* [project @ 2001-12-05 17:35:12 by sewardj]sewardj2001-12-051-148/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -------------------------------------------- Translate out PrimOps at the AbstractC level -------------------------------------------- This is the first in what might be a series of changes intended to make GHC less dependent on its C back end. The main change is to translate PrimOps into vanilla abstract C inside the compiler, rather than having to duplicate that work in each code generation route. The main changes are: * A new type, MachOp, in compiler/absCSyn/MachOp.hs. A MachOp is a primitive operation which we can reasonably expect the native code generators to implement. The set is quite small and unlikely to change much, if at all. * Translations from PrimOps to MachOps, at the end of absCSyn/AbsCUtils. This should perhaps be moved to a different module, but it is hard to see how to do this without creating a circular dep between it and AbsCUtils. * The x86 insn selector has been updated to track these changes. The sparc insn selector remains to be done. As a result of this, it is possible to compile much more code via the NCG than before. Almost all the Prelude can be compiled with it. Currently it does not know how to do 64-bit code generation. Once this is fixed, the entire Prelude should be compilable that way. I also took the opportunity to clean up the NCG infrastructure. The old Stix data type has been split into StixStmt (statements) and StixExpr (now denoting values only). This removes a class of impossible constructions and clarifies the NCG. Still to do, in no particular order: * String and literal lifting, currently done in the NCG at the top of nativeGen/MachCode, should be done in the AbstractC flattener, for the benefit of all targets. * Further cleaning up of Stix assignments. * Remove word-size dependency from Abstract C. (should be easy). * Translate out MagicIds in the AbsC -> Stix translation, not in the Stix constant folder. (!) Testsuite failures caused by this: * memo001 - fails (segfaults) for some unknown reason now. * arith003 - wrong answer in gcdInt boundary cases. * arith011 - wrong answer for shifts >= word size. * cg044 - wrong answer for some FP boundary cases. These should be fixed, but I don't think they are mission-critical for anyone.
* [project @ 2001-11-08 12:56:00 by simonmar]simonmar2001-11-081-7/+7
| | | | | | | | | | | Updates to the native code generator following the changes to fix the large block allocation bug, and changes to use the new function-address cache in the register table to reduce code size. Also: I changed the pretty-printing machinery for assembly code to use Pretty rather than Outputable, since we don't make use of the styles and it should improve performance. Perhaps the same should be done for abstract C.
* [project @ 2001-06-22 12:37:54 by rrt]rrt2001-06-221-1/+1
| | | | Correct path to NCG.h
* [project @ 2001-02-19 10:15:54 by sewardj]sewardj2001-02-191-13/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix two bugs exposed when trying to boot HEAD on sparc with NCG and -O: 1. StScratchWords on sparc were in the wrong place; they were immediately above %fp and should have been immediately below. Fixed. Also removed a suspicious-looking "+1" in the x86 version of same. 2. (Potentially affects all platforms): Lift strings out from top-level literal data, and place them at the end of the block. The motivating example (bug) was: Stix: (DataSegment) Bogon.ping_closure : (Data P_ Addr.A#_static_info) (Data StgAddr (Str `alalal')) (Data P_ (0)) results in: .data .align 8 .global Bogon_ping_closure Bogon_ping_closure: .long Addr_Azh_static_info .long .Ln1a8 .Ln1a8: .byte 0x61 .byte 0x6C .byte 0x61 .byte 0x6C .byte 0x61 .byte 0x6C .byte 0x00 .long 0 ie, the Str is planted in-line, when what we really meant was to place a _reference_ to the string there. This is Way Wrong (tm). Fixed.
* [project @ 2001-02-05 11:20:12 by simonmar]simonmar2001-02-051-7/+7
| | | | add some _scc_s
* [project @ 2000-11-06 08:15:20 by simonpj]simonpj2000-11-061-8/+8
| | | | Dealing with instance-decl imports; and removing unnecessary imports
* [project @ 2000-08-21 15:40:14 by sewardj]sewardj2000-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | Make the register allocator deal properly with switch tables. Previously, it didn't calculate the correct flow edges away from the indirect jump (in fact it didn't reckon there were any flow edges leaving it :) which makes a nonsense of the live variable analysis in the branches. A jump insn can now optionally be annotated with a list of destination labels, and if so, the register allocator creates flow edges to all of them. Jump tables are now re-enabled. They remain disabled for 4.08.1, since we aren't fixing the problem properly on that branch. I assume this problem wasn't exposed by the old register allocator because of the live-range-approximation hacks used in it. Since it was undocumented, we'll never know. Sparc builds will now break until I fix them.
* [project @ 2000-07-12 13:04:31 by sewardj]sewardj2000-07-121-1/+1
| | | | | | | | Make the x86 NCG work again following recent sparc hackage. Also, fix the x86 bits pertaining to the floats-promoted-to-doubles- in-ccalls problem. So this problem should no longer exist on x86 or sparc via NCG.
* [project @ 2000-07-11 15:26:33 by sewardj]sewardj2000-07-111-1/+1
| | | | | | | | | | | | | | | | | | Fix up the sparc native code generator. Mostly dull stuff. Notable changes: * Cleaned up ccall mechanism for sparc somewhat. * Rearranged assignment of sparc floating point registers (includes/MachRegs.h) so the NCG's register allocator can handle the double-single pairing issue without modification. Split VirtualRegF into VirtualRegF and VirtualRegD, and split RcFloating into RcFloat and RcDouble. Net effect is that there are now three register classes -- int, float and double, and we pretend that sparc has some float and some double real regs. * (A fix for all platforms): propagate MachFloats through as StFloats, not StDoubles. Amazingly, until now literal floats had been converted to and treated as doubles, including in ccalls.
* [project @ 2000-07-05 14:28:49 by sewardj]sewardj2000-07-051-5/+4
| | | | | | | | | Rename the marker used by Diff_Gcc_Nat.hs to ___ncg_debug_marker, to make it clear it has nothing to do with the usual object-splitting machinery. Improve Diff_Gcc_Nat: * Emit a warning, and stop, if there are no debug markers in the NCG code. * Handle .uahalf and .uaword, which appear in sparc assembly, but not x86.
* [project @ 2000-07-03 15:12:41 by simonmar]simonmar2000-07-031-10/+9
| | | | DEBUG ==> NCG_DEBUG
* [project @ 2000-06-15 08:38:25 by sewardj]sewardj2000-06-151-52/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Major thing: new register allocator. Brief description follows. Should correctly handle code with loops in, even though we don't generate any such at the moment. A lot of comments. The previous machinery for spilling is retained, as is the idea of a fast-and-easy initial allocation attempt intended to deal with the majority of code blocks (about 60% on x86) very cheaply. Many comments explaining in detail how it works :-) The Stix inliner is now on by default. Integer code seems to run within about 1% of that -fvia-C. x86 fp code is significantly worse, up to about 30% slower, depending on the amount of fp activity. Minor thing: lazyfication of the top-level NCG plumbing, so that the NCG doesn't require any greater residency than compiling to C, just a bit more time. Created lazyThenUs and lazyMapUs for this purpose. The new allocator is somewhat, although not catastophically, slower than the old one. Fixing of the long-standing NCG space leak more than makes up for it; overall hsc run-time is down about 5%, due to significantly reduced GC time. -------------------------------------------------------------------- Instructions are numbered sequentially, starting at zero. A flow edge (FE) is a pair of insn numbers (MkFE Int Int) denoting a possible flow of control from the first insn to the second. The input to the register allocator is a list of instructions, which mention Regs. A Reg can be a RealReg -- a real machine reg -- or a VirtualReg, which carries a unique. After allocation, all the VirtualReg references will have been converted into RealRegs, and possibly some spill code will have been inserted. The heart of the register allocator works in four phases. 1. (find_flow_edges) Calculate all the FEs for the code list. Return them not as a [FE], but implicitly, as a pair of Array Int [Int], being the successor and predecessor maps for instructions. 2. (calc_liveness) Returns a FiniteMap FE RegSet. For each FE, indicates the set of registers live on that FE. Note that the set includes both RealRegs and VirtualRegs. The former appear because the code could mention fixed register usages, and we need to take them into account from the start. 3. (calc_live_range_sets) Invert the above mapping, giving a FiniteMap Reg FeSet, indicating, for each virtual and real reg mentioned in the code, which FEs it is live on. 4. (calc_vreg_to_rreg_mapping) For virtual reg, try and find an allocatable real register for it. Each real register has a "current commitment", indicating the set of FEs it is currently live on. A virtual reg v can be assigned to real reg r iff v's live-fe-set does not intersect with r's current commitment fe-set. If the assignment is made, v's live-fe-set is union'd into r's current commitment fe-set. There is also the minor restriction that v and r must be of the same register class (integer or floating). Once this mapping is established, we simply apply it to the input insns, and that's it. If no suitable real register can be found, the vreg is mapped to itself, and we deem allocation to have failed. The partially allocated code is returned. The higher echelons of the allocator (doGeneralAlloc and runRegAlloc) then cooperate to insert spill code and re-run allocation, until a successful allocation is found.
* [project @ 2000-05-18 13:55:36 by sewardj]sewardj2000-05-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Teach the NCG about the dereferencing and naming conventions to be used when compiling for a DLLised world. Some cleanups on the way too. The scheme is that * All CLabels which are in different DLLs from the current module will, via the renamer, already be such that labelDynamic returns True for them. * Redo the StixPrim/StixMacro stuff so that all references to symbols in the RTS are via CLabels. That means that the usual labelDynamic story can be used. * When a label is printed in PprMach, labelDynamic is consulted, to generate the __imp_ prefix if necessary. * In MachCode.stmt2Instrs, selectively ask derefDLL to walk trees before code generation and insert deferencing code around other-DLL symbols. * When generating Stix for SRTs, add 1 to other-DLL refs. * When generating static closures, insert a zero word before the _closure label.
* [project @ 2000-04-28 15:05:04 by panne]panne2000-04-281-3/+1
| | | | Nuked trace message from NCG
* [project @ 2000-03-01 12:31:22 by sewardj]sewardj2000-03-011-2/+9
| | | | | | | | | Temporarily disable Stix inlining whilst we figure out how to fix obscure bugs in the register allocator. With inlining off, everything seems to work, and the compiler can boot itself, but when enabled, inlining exposes a register allocation bug which causes ghc/compiler/utils/FastString.lhs to be miscompiled on Linux (the big arithmetic expressions for computing hash values).
* [project @ 2000-02-28 12:02:31 by sewardj]sewardj2000-02-281-40/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many changes to improve the quality and correctness of generated code, both for x86 and all-platforms. The intent is that the x86 NCG will now be good enough for general use. -- Add an almost-trivial Stix (generic) peephole optimiser, whose sole purpose is elide assignments to temporaries used only once, in the very next tree. This generates substantially better code for conditionals on all platforms. Enhance Stix constant folding to take advantage of the inlining. The inlining presents subsequent insn selection phases with more complex trees than would have previously been used to. This has shown up several bugs in the x86 insn selectors, now fixed. (assumptions that data size is Word, when could be Byte, assumptions that an operand will always be in a temp reg, etc) -- x86: Use the FLDZ and FLD1 insns. -- x86: spill FP registers with 80-bit loads/stores so that Intel's extra 16 bits of accuracy are not lost. If this isn't done, FP spills are not suitably transparent. Increase the number of spill words available to 2048. -- x86: give the register allocator more flexibility in choosing spill temporaries. -- x86, RegAllocInfo.regUsage: fix error for GST, and rewrite to make it clearer. -- Correctly track movements in the C stack pointer, and generate correct spill code for archs which spill against the stack pointer even when the stack pointer moves. Redo the x86 ccall mechanism to push args on the C stack in the normal way. Rather than have the spiller have to analyse code sequences to determine the current stack offset, the insn selectors communicate the current offset whenever it changes by inserting a DELTA pseudo-insn. Then the spiller only has to spot DELTAs. This means having a new native-code-generator monad (Stix.NatM) which carries both a UniqSupply and the current stack offset. -- Remove the asmPar/asmSeq ways of grouping insns together. In the presence of fixed registers, it is hard to demonstrate that insn selectors using asmPar always give correct code, and the extra complication doesn't help any. Also, directly construct code sequences using tree-based ordered lists (utils/OrdList.lhs) for linear-time appends, rather than the bizarrely complex method using fns and fn composition. -- Inline some hcats in printing of x86 address modes. -- Document more of the hidden assumptions which insn selection relies on, particular wrt addressing modes.
* [project @ 2000-02-03 18:01:03 by sewardj]sewardj2000-02-031-0/+1
| | | | | | | | | Fix x86 NCG so the compiler can compile itself `-O': -- Implement fake x86 insn GITOD/GITOF. -- Implement primops ReadMutVarOp and WriteMutVarOp. -- Pro tem, disable use of %eax as a spill temp. -- Clarify wording of Rules of the Game comment in MachCode.
* [project @ 2000-02-02 11:40:33 by sewardj]sewardj2000-02-021-2/+9
| | | | | | | | | | | | | | | | | trivialCode on x86 is the heart of instruction selection for expressions. It is definitely a non-trivial in complexity. To generate correct code it needs to observe preserve several delicate invariants, but didn't. -- Recorded in MachCode.lhs the "Rules of the Game"; ie what I think the required invariants are. -- Completely rewrote trivialCode (also shift_code). I think it should handle all cases correctly, and has special treatment for literal operands. -- Updated NOTES file to record issues which need to be resolved before x86 nativeGen can be considered ready for public use.
* [project @ 2000-01-28 18:07:55 by sewardj]sewardj2000-01-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Modifications to make x86 register spilling to work reasonably. It should work ok most of the time, although there is still a remote possibility that the allocator simply will be unable to complete spilling, and will just give up. -- Incrementally try with 0, 1, 2 and 3 spill regs, so as not to unduly restrict the supply of regs in code which doesn't need spilling. -- Remove the use of %ecx for shift values, so it is always available as the first-choice spill temporary. For code which doesn't do int division, make %edx and %eax available for spilling too. Shifts by a non-constant amount (very rare) are now done by a short test-and-jump sequence, so that %ecx is not tied up. -- x86 FP: do sin, cos, tan in-line so we get the same answers as gcc. -- Moved a little code around to remove recursive dependencies. -- Fix a subtle bug in x86 regUsage, which could cause underestimation of live ranges.
* [project @ 2000-01-28 09:40:05 by sewardj]sewardj2000-01-281-2/+3
| | | | | | | | | | | | | | | | Commit all changes prior to addressing the x86 spilling situation in the register allocator. -- Fix nonsensical x86 addressing mode hacks in mangleIndexTree and getAmode. -- Make char-sized loads work properly, using MOVZBL. -- In assignIntCode, use primRep on the assign node to determine the size of data transfer, not the size of the source. -- Redo Integer primitives to be in line with current representation of Integers.
* [project @ 2000-01-26 13:40:54 by sewardj]sewardj2000-01-261-3/+8
| | | | | | | | Observe the C conventions for use of the FP register stack. In particular, free up any live fp registers prior to non-local control transfers. Sigh. This is not good. The FP situation needs to be reviewed once the rest of x86 nativeGen is stable.
* [project @ 2000-01-24 17:24:23 by sewardj]sewardj2000-01-241-72/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Major reworking of the x86 floating point code generation. Intel, in their infinite wisdom, selected a stack model for floating point registers on x86. That might have made sense back in 1979 -- nowadays we can see it for the nonsense it really is. A stack model fits poorly with the existing nativeGen infrastructure, which assumes flat integer and FP register sets. Prior to this commit, nativeGen could not generate correct x86 FP code -- to do so would have meant somehow working the register-stack paradigm into the register allocator and spiller, which sounds very difficult. We have decided to cheat, and go for a simple fix which requires no infrastructure modifications, at the expense of generating ropey but correct FP code. All notions of the x86 FP stack and its insns have been removed. Instead, we pretend (to the instruction selector and register allocator) that x86 has six floating point registers, %fake0 .. %fake5, which can be used in the usual flat manner. We further claim that x86 has floating point instructions very similar to SPARC and Alpha, that is, a simple 3-operand register-register arrangement. Code generation and register allocation proceed on this basis. When we come to print out the final assembly, our convenient fiction is converted to dismal reality. Each fake instruction is independently converted to a series of real x86 instructions. %fake0 .. %fake5 are mapped to %st(0) .. %st(5). To do reg-reg arithmetic operations, the two operands are pushed onto the top of the FP stack, the operation done, and the result copied back into the relevant register. There are only six %fake registers because 2 are needed for the translation, and x86 has 8 in total. The translation is inefficient but is simple and it works. A cleverer translation would handle a sequence of insns, simulating the FP stack contents, would not impose a fixed mapping from %fake to %st regs, and hopefully could avoid most of the redundant reg-reg moves of the current translation.