Skip to content
  1. Nov 09, 2013
    • Chandler Carruth's avatar
      Move the old pass manager infrastructure into a legacy namespace and · 7caea415
      Chandler Carruth authored
      give the files a legacy prefix in the right directory. Use forwarding
      headers in the old locations to paper over the name change for most
      clients during the transitional period.
      
      No functionality changed here! This is just clearing some space to
      reduce renaming churn later on with a new system.
      
      Even when the new stuff starts to go in, it is going to be hidden behind
      a flag and off-by-default as it is still WIP and under development.
      
      This patch is specifically designed so that very little out-of-tree code
      has to change. I'm going to work as hard as I can to keep that the case.
      Only direct forward declarations of the PassManager class are impacted
      by this change.
      
      llvm-svn: 194324
      7caea415
  2. Oct 31, 2013
  3. Oct 30, 2013
    • Rafael Espindola's avatar
      Add calls to doInitialization() and doFinalization() in verifyFunction() · 55fdcff4
      Rafael Espindola authored
      The function verifyFunction() in lib/IR/Verifier.cpp misses some
      calls. It creates a temporary FunctionPassManager that will run a
      single Verifier pass. Unfortunately, FunctionPassManager is no
      PassManager and does not call doInitialization() and doFinalization()
      by itself. Verifier does important tasks in doInitialization() such as
      collecting type information used to check DebugInfo metadata and
      doFinalization() does some additional checks. Therefore these checks
      were missed and debug info couldn't be verified at all, it just
      crashed if the function had some.
      
      verifyFunction() is currently not used in llvm unless -debug option is
      enabled, and in unittests/IR/VerifierTest.cpp
      
      VerifierTest had to be changed to create the function in a module from
      which the type debug info can be collected.
      
      Patch by Michael Kruse.
      
      llvm-svn: 193719
      55fdcff4
  4. Oct 05, 2013
  5. Sep 30, 2013
  6. Sep 09, 2013
    • Bob Wilson's avatar
      Revert patches to add case-range support for PR1255. · e407736a
      Bob Wilson authored
      The work on this project was left in an unfinished and inconsistent state.
      Hopefully someone will eventually get a chance to implement this feature, but
      in the meantime, it is better to put things back the way the were.  I have
      left support in the bitcode reader to handle the case-range bitcode format,
      so that we do not lose bitcode compatibility with the llvm 3.3 release.
      
      This reverts the following commits: 155464, 156374, 156377, 156613, 156704,
      156757, 156804 156808, 156985, 157046, 157112, 157183, 157315, 157384, 157575,
      157576, 157586, 157612, 157810, 157814, 157815, 157880, 157881, 157882, 157884,
      157887, 157901, 158979, 157987, 157989, 158986, 158997, 159076, 159101, 159100,
      159200, 159201, 159207, 159527, 159532, 159540, 159583, 159618, 159658, 159659,
      159660, 159661, 159703, 159704, 160076, 167356, 172025, 186736
      
      llvm-svn: 190328
      e407736a
  7. Aug 03, 2013
  8. Jul 31, 2013
  9. Jul 30, 2013
  10. Jun 29, 2013
  11. Jun 19, 2013
  12. May 05, 2013
    • Arnold Schwaighofer's avatar
      Add missing PatternMatch.cpp to CMakeLists.txt · eb4f2d63
      Arnold Schwaighofer authored
      llvm-svn: 181147
      eb4f2d63
    • Arnold Schwaighofer's avatar
      PatternMatch: Matcher for (un)ordered floating point min/max · e972d03f
      Arnold Schwaighofer authored
      Add support for matching 'ordered' and 'unordered' floating point min/max
      constructs.
      
      In LLVM we can express min/max functions as a combination of compare and select.
      We have support for matching such constructs for integers but not for floating
      point. In floating point math there is no total order because of the presence of
      'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics
      when interpreting floating point compare select combinations as a minimum or
      maximum function. The resulting 'ordered/unordered' floating point maximum
      function has to select the same value as the select/fcmp combination it is based
      on.
      
       ordered_max(x,y)   = max(x,y) iff x and y are not NaN, y otherwise
       unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise
       ordered_min(x,y)   = min(x,y) iff x and y are not NaN, y otherwise
       unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise
      
      This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R)
      construct.
      
      Any code using this predicate has to preserve this semantics.
      
      A follow-up patch will use this to implement floating point min/max reductions
      in the vectorizer.
      
      radar://13723044
      
      llvm-svn: 181143
      e972d03f
  13. Apr 12, 2013
  14. Jan 31, 2013
  15. Jan 27, 2013
  16. Jan 23, 2013
  17. Jan 16, 2013
  18. Jan 14, 2013
  19. Jan 12, 2013
  20. Jan 07, 2013
Loading