Skip to content
  1. May 22, 2011
  2. Mar 22, 2011
  3. Mar 18, 2011
  4. Mar 02, 2011
    • Rafael Espindola's avatar
      Add a special streamer to libLTO that just records symbols definitions and · 1e49a6d9
      Rafael Espindola authored
      uses.
      
      The result produced by the streamer is used to give the linker more accurate
      information and to add to llvm.compiler.used. The second improvement removes
      the need for the user to add __attribute__((used)) to functions only used in
      inline asm. The first one lets us build firefox with LTO on Darwin :-)
      
      llvm-svn: 126830
      1e49a6d9
  5. Feb 24, 2011
  6. Feb 20, 2011
  7. Feb 12, 2011
  8. Feb 11, 2011
  9. Dec 16, 2010
  10. Dec 10, 2010
  11. Dec 09, 2010
  12. Dec 06, 2010
  13. Dec 04, 2010
  14. Nov 29, 2010
  15. Oct 07, 2010
  16. Sep 01, 2010
  17. Aug 20, 2010
  18. Aug 11, 2010
  19. Aug 10, 2010
  20. May 27, 2010
  21. May 11, 2010
    • Bill Wendling's avatar
      The getDefaultSubtargetFeatures method of SubtargetFeature did actually return a · a12c1ff2
      Bill Wendling authored
      string of features for that target. However LTO was using that string to pass
      into the "create target machine" stuff. That stuff needed the feature string to
      be in a particular form. In particular, it needed the CPU specified first and
      then the attributes. If there isn't a CPU specified, it required it to be blank
      -- e.g., ",+altivec". Yuck.
      
      Modify the getDefaultSubtargetFeatures method to be a non-static member
      function. For all attributes for a specific subtarget, it will add them in like
      normal. It will also take a CPU string so that it can satisfy this horrible
      syntax.
      
      llvm-svn: 103451
      a12c1ff2
  22. May 02, 2010
  23. Apr 27, 2010
  24. Apr 17, 2010
  25. Mar 24, 2010
  26. Mar 12, 2010
  27. Feb 03, 2010
  28. Feb 02, 2010
  29. Jan 27, 2010
    • Jeffrey Yasskin's avatar
      Kill ModuleProvider and ghost linkage by inverting the relationship between · 091217be
      Jeffrey Yasskin authored
      Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
      GlobalValues now, and doesn't provide modules, it's renamed to
      "GVMaterializer". Code that used to need a ModuleProvider to materialize
      Functions can now materialize the Functions directly. Functions no longer use a
      magic linkage to record that they're materializable; they simply ask the
      GVMaterializer.
      
      Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
      the functions that refer to it. Instead, because Module now exposes the same
      functionality ModuleProvider used to, we store a Module* in any
      LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
      other languages still use the ModuleProvider concept.  It would probably be
      worth some time to update them to follow the C++ more closely, but I don't
      intend to do it.
      
      Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
      
      llvm-svn: 94686
      091217be
  30. Jan 17, 2010
  31. Jan 16, 2010
Loading