Skip to content
  1. Dec 18, 2010
  2. Nov 29, 2010
  3. Oct 19, 2010
  4. Oct 06, 2010
  5. Sep 01, 2010
  6. Aug 26, 2010
    • Dan Gohman's avatar
      Reapply r112091 and r111922, support for metadata linking, with a · ca26f790
      Dan Gohman authored
      fix: add a flag to MapValue and friends which indicates whether
      any module-level mappings are being made. In the common case of
      inlining, no module-level mappings are needed, so MapValue doesn't
      need to examine non-function-local metadata, which can be very
      expensive in the case of a large module with really deep metadata
      (e.g. a large C++ program compiled with -g).
      
      This flag is a little awkward; perhaps eventually it can be moved
      into the ClonedCodeInfo class.
      
      llvm-svn: 112190
      ca26f790
    • Daniel Dunbar's avatar
      Revert r112091, "Remap metadata attached to instructions when remapping · 95fe13c7
      Daniel Dunbar authored
      individual ...", which depends on r111922, which I am reverting.
      
      llvm-svn: 112157
      95fe13c7
  7. Aug 25, 2010
  8. Aug 24, 2010
  9. Aug 15, 2010
  10. Aug 14, 2010
  11. Jul 22, 2010
  12. Jun 30, 2010
  13. Jun 29, 2010
    • Bill Wendling's avatar
      Introducing the "linker_weak" linkage type. This will be used for Objective-C · 1767723d
      Bill Wendling authored
      metadata types which should be marked as "weak", but which the linker will
      remove upon final linkage. For example, the "objc_msgSend_fixup_alloc" symbol is
      defined like this:
      
             .globl l_objc_msgSend_fixup_alloc
             .weak_definition l_objc_msgSend_fixup_alloc
             .section __DATA, __objc_msgrefs, coalesced
             .align 3
      l_objc_msgSend_fixup_alloc:
              .quad   _objc_msgSend_fixup
              .quad   L_OBJC_METH_VAR_NAME_1
      
      This is different from the "linker_private" linkage type, because it can't have
      the metadata defined with ".weak_definition".
      
      llvm-svn: 107205
      1767723d
  14. Feb 16, 2010
  15. Feb 06, 2010
  16. Jan 27, 2010
  17. Jan 22, 2010
  18. Jan 09, 2010
    • David Chisnall's avatar
      Fixed linking of modules containing aliases to constant bitcasts. Existing... · 2c4a34ae
      David Chisnall authored
      Fixed linking of modules containing aliases to constant bitcasts.  Existing behaviour first tried to replace the aliases with the global that they aliased (rather than the bitcast), causing a crash on an assert because the types didn't match.  When this was fixed, it then did the same thing creating the new alias (creating an alias with a different type to its aliasee).  
      
      Linking modules containing aliases to GEPs is still not quite right.  GEPs that are equivalent to bitcasts will be replaced by bitcasts, GEPs that are not will just break.  Aliases to GEPs that are not equivalent to bitcasts are horribly broken anyway (it might be worth adding an assert when creating the alias to prevent these being created; they just cause problems later).
      
      llvm-svn: 93052
      2c4a34ae
  19. Jan 05, 2010
  20. Dec 31, 2009
  21. Dec 28, 2009
  22. Nov 01, 2009
  23. Sep 13, 2009
  24. Sep 03, 2009
  25. Aug 24, 2009
    • Chris Lattner's avatar
      Prune #includes from llvm/Linker.h and llvm/System/Path.h, · c521f541
      Chris Lattner authored
      forcing them down into various .cpp files.
      
      This change also:
      1. Renames TimeValue::toString() and Path::toString() to ::str()
         for similarity with the STL.
      2. Removes all stream insertion support for sys::Path, forcing
         clients to call .str().
      3. Removes a use of Config/alloca.h from bugpoint, using smallvector
         instead.
      4. Weans llvm-db off <iostream>
      
      sys::Path really needs to be gutted, but I don't have the desire to
      do it at this point.
      
      llvm-svn: 79869
      c521f541
  26. Aug 23, 2009
  27. Aug 11, 2009
  28. Jul 31, 2009
  29. Jul 30, 2009
Loading