1. 25 Feb, 2020 1 commit
  2. 22 Feb, 2020 1 commit
  3. 25 Jan, 2020 1 commit
  4. 17 Nov, 2018 1 commit
    • Andreas Klebinger's avatar
      NCG: New code layout algorithm. · 912fd2b6
      Andreas Klebinger authored
      Summary:
      This patch implements a new code layout algorithm.
      It has been tested for x86 and is disabled on other platforms.
      
      Performance varies slightly be CPU/Machine but in general seems to be better
      by around 2%.
      Nofib shows only small differences of about +/- ~0.5% overall depending on
      flags/machine performance in other benchmarks improved significantly.
      
      Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec,
      containers, text and xeno.
      
      While the magnitude of gains differed three different CPUs where tested with
      all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell,
      Skylake
      
      * Library benchmark results summarized:
        * containers: ~1.5% faster
        * aeson: ~2% faster
        * megaparsec: ~2-5% faster
        * xml library benchmarks: 0.2%-1.1% faster
        * vector-benchmarks: 1-4% faster
        * text: 5.5% faster
      
      On average GHC compile times go down, as GHC compiled with the new layout
      is faster than the overhead introduced by using the new layout algorithm,
      
      Things this patch does:
      
      * Move code responsilbe for block layout in it's own module.
      * Move the NcgImpl Class into the NCGMonad module.
      * Extract a control flow graph from the input cmm.
      * Update this cfg to keep it in sync with changes during
        asm codegen. This has been tested on x64 but should work on x86.
        Other platforms still use the old codelayout.
      * Assign weights to the edges in the CFG based on type and limited static
        analysis which are then used for block layout.
      * Once we have the final code layout eliminate some redundant jumps.
      
        In particular turn a sequences of:
            jne .foo
            jmp .bar
          foo:
        into
            je bar
          foo:
            ..
      
      Test Plan: ci
      
      Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton
      
      GHC Trac Issues: #15124
      
      Differential Revision: https://phabricator.haskell.org/D4726
      912fd2b6
  5. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  6. 06 Apr, 2013 1 commit
  7. 14 Sep, 2012 1 commit
  8. 31 May, 2011 3 commits
  9. 06 May, 2010 1 commit
  10. 18 May, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Split Reg into vreg/hreg and add register pairs · f9288086
      Ben.Lippmeier@anu.edu.au authored
       * The old Reg type is now split into VirtualReg and RealReg.
       * For the graph coloring allocator, the type of the register graph
         is now (Graph VirtualReg RegClass RealReg), which shows that it colors
         in nodes representing virtual regs with colors representing real regs.
         (as was intended)  
       * RealReg contains two contructors, RealRegSingle and RealRegPair,
         where RealRegPair is used to represent a SPARC double reg 
         constructed from two single precision FP regs. 
       * On SPARC we can now allocate double regs into an arbitrary register
         pair, instead of reserving some reg ranges to only hold float/double values. 
      f9288086
  11. 15 Feb, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      NCG: Split up the native code generator into arch specific modules · b04a210e
      Ben.Lippmeier@anu.edu.au authored
        - nativeGen/Instruction defines a type class for a generic
          instruction set. Each of the instruction sets we have, 
          X86, PPC and SPARC are instances of it.
        
        - The register alloctors use this type class when they need
          info about a certain register or instruction, such as
          regUsage, mkSpillInstr, mkJumpInstr, patchRegs..
        
        - nativeGen/Platform defines some data types enumerating
          the architectures and operating systems supported by the 
          native code generator.
        
        - DynFlags now keeps track of the current build platform, and 
          the PositionIndependentCode module uses this to decide what
          to do instead of relying of #ifdefs.
        
        - It's not totally retargetable yet. Some info info about the
          build target is still hardwired, but I've tried to contain
          most of it to a single module, TargetRegs.
        
        - Moved the SPILL and RELOAD instructions into LiveInstr.
        
        - Reg and RegClass now have their own modules, and are shared
          across all architectures.
      b04a210e
  12. 04 Feb, 2009 3 commits
  13. 03 Feb, 2009 1 commit
  14. 02 Feb, 2009 1 commit