Skip to content
  1. Mar 11, 2009
  2. 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
  3. Dec 19, 2008
  4. Dec 17, 2008
  5. Nov 03, 2008
  6. Sep 25, 2008
    • Devang Patel's avatar
      Large mechanical patch. · 4c758ea3
      Devang Patel authored
      s/ParamAttr/Attribute/g
      s/PAList/AttrList/g
      s/FnAttributeWithIndex/AttributeWithIndex/g
      s/FnAttr/Attribute/g
      
      This sets the stage 
      - to implement function notes as function attributes and 
      - to distinguish between function attributes and return value attributes.
      
      This requires corresponding changes in llvm-gcc and clang.
      
      llvm-svn: 56622
      4c758ea3
  7. Aug 30, 2008
  8. Aug 17, 2008
    • Gordon Henriksen's avatar
      Rename some GC classes so that their roll will hopefully be clearer. · d930f913
      Gordon Henriksen authored
      In particular, Collector was confusing to implementors. Several
      thought that this compile-time class was the place to implement
      their runtime GC heap. Of course, it doesn't even exist at runtime.
      Specifically, the renames are:
      
        Collector               -> GCStrategy
        CollectorMetadata       -> GCFunctionInfo
        CollectorModuleMetadata -> GCModuleInfo
        CollectorRegistry       -> GCRegistry
        Function::getCollector  -> getGC (setGC, hasGC, clearGC)
      
      Several accessors and nested types have also been renamed to be
      consistent. These changes should be obvious.
      
      llvm-svn: 54899
      d930f913
  9. Aug 09, 2008
  10. Aug 08, 2008
  11. May 19, 2008
  12. May 04, 2008
  13. Apr 28, 2008
  14. Apr 25, 2008
  15. Apr 13, 2008
  16. Mar 23, 2008
  17. Mar 19, 2008
  18. Mar 16, 2008
  19. Mar 15, 2008
  20. Mar 07, 2008
  21. Feb 02, 2008
  22. Jan 01, 2008
  23. Dec 30, 2007
  24. Dec 29, 2007
  25. Dec 27, 2007
  26. Dec 19, 2007
  27. Dec 17, 2007
  28. Dec 12, 2007
  29. Dec 10, 2007
    • Gordon Henriksen's avatar
      Adding a collector name attribute to Function in the IR. These · 71183b67
      Gordon Henriksen authored
      methods are new to Function:
      
        bool hasCollector() const;
        const std::string &getCollector() const;
        void setCollector(const std::string &);
        void clearCollector();
      
      The assembly representation is as such:
      
        define void @f() gc "shadow-stack" { ...
      
      The implementation uses an on-the-side table to map Functions to 
      collector names, such that there is no overhead. A StringPool is 
      further used to unique collector names, which are extremely
      likely to be unique per process.
      
      llvm-svn: 44769
      71183b67
  30. Oct 08, 2007
  31. Oct 07, 2007
Loading