Skip to content
  1. Mar 01, 2014
  2. Feb 28, 2014
    • Reid Kleckner's avatar
      [CMake] Remove dead C backend option · 7c8743da
      Reid Kleckner authored
      Patch by Jevin Sweval!
      
      llvm-svn: 202556
      7c8743da
    • Reid Kleckner's avatar
      Reflow isProfitableToMakeFastCC · e6ff5c51
      Reid Kleckner authored
      llvm-svn: 202555
      e6ff5c51
    • Lang Hames's avatar
      Jumped the gun with r202551 and broke some bots that weren't yet C++11ified. · c083578a
      Lang Hames authored
      Reverting until the C++11 switch is complete.
      
      llvm-svn: 202554
      c083578a
    • Lang Hames's avatar
      New PBQP solver, and updates to the PBQP graph. · 525a2123
      Lang Hames authored
      The previous PBQP solver was very robust but consumed a lot of memory,
      performed a lot of redundant computation, and contained some unnecessarily tight
      coupling that prevented experimentation with novel solution techniques. This new
      solver is an attempt to address these shortcomings.
      
      Important/interesting changes:
      
      1) The domain-independent PBQP solver class, HeuristicSolverImpl, is gone.
      It is replaced by a register allocation specific solver, PBQP::RegAlloc::Solver
      (see RegAllocSolver.h).
      
      The optimal reduction rules and the backpropagation algorithm have been extracted
      into stand-alone functions (see ReductionRules.h), which can be used to build
      domain specific PBQP solvers. This provides many more opportunities for
      domain-specific knowledge to inform the PBQP solvers' decisions. In theory this
      should allow us to generate better solutions. In practice, we can at least test
      out ideas now.
      
      As a side benefit, I believe the new solver is more readable than the old one.
      
      2) The solver type is now a template parameter of the PBQP graph.
      
      This allows the graph to notify the solver of any modifications made (e.g. by
      domain independent rules) without the overhead of a virtual call. It also allows
      the solver to supply policy information to the graph (see below).
      
      3) Significantly reduced memory overhead.
      
      Memory management policy is now an explicit property of the PBQP graph (via
      the CostAllocator typedef on the graph's solver template argument). Because PBQP
      graphs for register allocation tend to contain many redundant instances of
      single values (E.g. the value representing an interference constraint between
      GPRs), the new RASolver class uses a uniquing scheme. This massively reduces
      memory consumption for large register allocation problems. For example, looking
      at the largest interference graph in each of the SPEC2006 benchmarks (the
      largest graph will always set the memory consumption high-water mark for PBQP),
      the average memory reduction for the PBQP costs was 400x. That's times, not
      percent. The highest was 1400x. Yikes. So - this is fixed.
      
      "PBQP: No longer feasting upon every last byte of your RAM".
      
      Minor details:
      
      - Fully C++11'd. Never copy-construct another vector/matrix!
      
      - Cute tricks with cost metadata: Metadata that is derived solely from cost
      matrices/vectors is attached directly to the cost instances themselves. That way
      if you unique the costs you never have to recompute the metadata. 400x less
      memory means 400x less cost metadata (re)computation.
      
      Special thanks to Arnaud de Grandmaison, who has been the source of much
      encouragement, and of many very useful test cases.
      
      This new solver forms the basis for future work, of which there's plenty to do.
      I will be adding TODO notes shortly.
      
      - Lang.
      
      llvm-svn: 202551
      525a2123
    • Chandler Carruth's avatar
      [docs] Clarify that there isn't much to be done other than watch build · 6e390fae
      Chandler Carruth authored
      bots when using the standard library facilities. The missing pieces here
      aren't always in useful discreet chunks.
      
      Fortunately, the missing pieces are few and far between, and we can
      emulate most of them in our headers as needed.
      
      Based on feedback from Lang and Dave.
      
      llvm-svn: 202548
      6e390fae
    • Chandler Carruth's avatar
      [C++11] Switch autoconf and make to use C++11 by default. Now both build · f9220533
      Chandler Carruth authored
      systems have the default as C++11, but retain the ability to build with
      C++98.
      
      Again, please restrain your enthusiasm a bit in case this needs to be
      reverted. =]
      
      llvm-svn: 202546
      f9220533
    • Eric Christopher's avatar
      Fix >> to be > > for non-c++11. · e587c085
      Eric Christopher authored
      llvm-svn: 202545
      e587c085
    • Tom Stellard's avatar
      R600: Verify all instructions in the AsmPrinter on debug builds · 9b9e9264
      Tom Stellard authored
      Make a call to R600's implementation of verifyInstruction() to
      check that instructions are only using legal operands.
      
      llvm-svn: 202544
      9b9e9264
    • Tom Stellard's avatar
      R600/SI: Expand all v16[if]32 operations · d61a1c33
      Tom Stellard authored
      llvm-svn: 202543
      d61a1c33
    • Chandler Carruth's avatar
      [C++11] Switch CMake to use C++11 by default! Next up, autoconf/make! · 83163ee1
      Chandler Carruth authored
      Now, please don't get too excited. I've just toggled the default to suss
      out the last remaining bot problems. This does *not* mean we can all go
      write lots of C++11 code yet. I at least want to let the dust settle
      from the bots first.
      
      llvm-svn: 202542
      83163ee1
Loading