Skip to content
  1. Apr 30, 2009
  2. Apr 29, 2009
    • Bill Wendling's avatar
      Second attempt: · 084669a1
      Bill Wendling authored
      Massive check in. This changes the "-fast" flag to "-O#" in llc. If you want to
      use the old behavior, the flag is -O0. This change allows for finer-grained
      control over which optimizations are run at different -O levels.
      
      Most of this work was pretty mechanical. The majority of the fixes came from
      verifying that a "fast" variable wasn't used anymore. The JIT still uses a
      "Fast" flag. I'll change the JIT with a follow-up patch.
      
      llvm-svn: 70343
      084669a1
  3. Apr 28, 2009
  4. Apr 10, 2009
  5. Apr 03, 2009
  6. Mar 26, 2009
  7. Mar 25, 2009
  8. Mar 21, 2009
  9. Mar 19, 2009
  10. Mar 16, 2009
  11. Mar 11, 2009
  12. Mar 07, 2009
    • Duncan Sands's avatar
      Introduce new linkage types linkonce_odr, weak_odr, common_odr · 12da8ce3
      Duncan Sands authored
      and extern_weak_odr.  These are the same as the non-odr versions,
      except that they indicate that the global will only be overridden
      by an *equivalent* global.  In C, a function with weak linkage can
      be overridden by a function which behaves completely differently.
      This means that IP passes have to skip weak functions, since any
      deductions made from the function definition might be wrong, since
      the definition could be replaced by something completely different
      at link time.   This is not allowed in C++, thanks to the ODR
      (One-Definition-Rule): if a function is replaced by another at
      link-time, then the new function must be the same as the original
      function.  If a language knows that a function or other global can
      only be overridden by an equivalent global, it can give it the
      weak_odr linkage type, and the optimizers will understand that it
      is alright to make deductions based on the function body.  The
      code generators on the other hand map weak and weak_odr linkage
      to the same thing.
      
      llvm-svn: 66339
      12da8ce3
  13. Feb 24, 2009
  14. Feb 23, 2009
  15. Feb 19, 2009
  16. Feb 18, 2009
  17. Feb 13, 2009
  18. Feb 12, 2009
  19. Feb 09, 2009
  20. Feb 07, 2009
    • Dan Gohman's avatar
      Constify TargetInstrInfo::EmitInstrWithCustomInserter, allowing · 747e55bc
      Dan Gohman authored
      ScheduleDAG's TLI member to use const.
      
      llvm-svn: 64018
      747e55bc
    • Dale Johannesen's avatar
      Get rid of the last non-DebugLoc versions of getNode! · 62fd95d6
      Dale Johannesen authored
      Many targets build placeholder nodes for special operands, e.g.
      GlobalBaseReg on X86 and PPC for the PIC base.  There's no
      sensible way to associate debug info with these.  I've left
      them built with getNode calls with explicit DebugLoc::getUnknownLoc operands. 
      I'm not too happy about this but don't see a good improvement;
      I considered adding a getPseudoOperand or something, but it
      seems to me that'll just make it harder to read.
      
      llvm-svn: 63992
      62fd95d6
  21. Feb 06, 2009
  22. Feb 05, 2009
  23. Feb 04, 2009
  24. Jan 26, 2009
  25. Jan 20, 2009
  26. Jan 15, 2009
  27. Jan 12, 2009
  28. Jan 09, 2009
  29. Jan 05, 2009
  30. Jan 01, 2009
    • Duncan Sands's avatar
      Fix PR3274: when promoting the condition of a BRCOND node, · 8feb694e
      Duncan Sands authored
      promote from i1 all the way up to the canonical SetCC type.
      In order to discover an appropriate type to use, pass
      MVT::Other to getSetCCResultType.  In order to be able to
      do this, change getSetCCResultType to take a type as an
      argument, not a value (this is also more logical).
      
      llvm-svn: 61542
      8feb694e
  31. Dec 14, 2008
  32. Dec 03, 2008
  33. Dec 01, 2008
  34. Nov 24, 2008
Loading