Skip to content
  1. Feb 11, 2011
  2. Dec 16, 2010
  3. Dec 10, 2010
  4. Dec 09, 2010
  5. Dec 06, 2010
  6. Dec 04, 2010
  7. Nov 29, 2010
  8. Oct 07, 2010
  9. Sep 01, 2010
  10. Aug 20, 2010
  11. Aug 11, 2010
  12. Aug 10, 2010
  13. May 27, 2010
  14. 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
  15. May 02, 2010
  16. Apr 27, 2010
  17. Apr 17, 2010
  18. Mar 24, 2010
  19. Mar 12, 2010
  20. Feb 03, 2010
  21. Feb 02, 2010
  22. 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
  23. Jan 17, 2010
  24. Jan 16, 2010
  25. Jan 15, 2010
  26. Jan 11, 2010
  27. Nov 25, 2009
  28. Nov 21, 2009
  29. Nov 18, 2009
  30. Nov 17, 2009
  31. Aug 25, 2009
Loading