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