Skip to content
  1. Oct 03, 2013
    • Rafael Espindola's avatar
      Optimize linkonce_odr unnamed_addr functions during LTO. · cda2911c
      Rafael Espindola authored
      Generalize the API so we can distinguish symbols that are needed just for a DSO
      symbol table from those that are used from some native .o.
      
      The symbols that are only wanted for the dso symbol table can be dropped if
      llvm can prove every other dso has a copy (linkonce_odr) and the address is not
      important (unnamed_addr).
      
      llvm-svn: 191922
      cda2911c
  2. Sep 25, 2013
  3. Aug 27, 2013
    • Shuxin Yang's avatar
      Revert 189297, the original commit message is following. · 388b52c0
      Shuxin Yang authored
      ----
        Add new API lto_codegen_compile_parallel().
      
        This API is proposed by Nick Kledzik. The semantic is:
      
        --------------------------------------------------------------------------
         Generate code for merged module into an array of native object files. On 
         success returns a pointer to an array of NativeObjectFile.  The count 
         parameter returns the number of elements in the array.  Each element is 
         a pointer/length for a generated mach-o/ELF buffer.  The buffer is owned
         by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, 
         or lto_codegen_compile() is called again. On failure, returns NULL 
         (check lto_get_error_message() for details).
      
         extern const struct  NativeObjectFile*
         lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
        ---------------------------------------------------------------------------
      
        This API is currently only called on OSX platform. Linux or other Unixes
      using GNU gold are not supposed to call this function, because on these systems, 
      object files are fed back to linker via disk file instead of memory buffer.
      
        In this commit, lto_codegen_compile_parallel() simply calls
      lto_codegen_compile() to return a single object file. In the near future,
      this function is the entry point for compilation with partition. Linker can
      blindly call this function even if partition is turned off; in this case,
      compiler will return only one object file.
      
      llvm-svn: 189386
      388b52c0
    • Shuxin Yang's avatar
      Add new API lto_codegen_compile_parallel(). · a44362e4
      Shuxin Yang authored
        This API is proposed by Nick Kledzik. The semantic is:
      
        --------------------------------------------------------------------------
         Generate code for merged module into an array of native object files. On 
         success returns a pointer to an array of NativeObjectFile.  The count 
         parameter returns the number of elements in the array.  Each element is 
         a pointer/length for a generated mach-o/ELF buffer.  The buffer is owned
         by the lto_code_gen_t and will be freed when lto_codegen_dispose() is called, 
         or lto_codegen_compile() is called again. On failure, returns NULL 
         (check lto_get_error_message() for details).
      
         extern const struct  NativeObjectFile*
         lto_codegen_compile_parallel(lto_code_gen_t cg, size_t *count);
        ---------------------------------------------------------------------------
      
        This API is currently only called on OSX platform. Linux or other Unixes
      using GNU gold are not supposed to call this function, because on these systems, 
      object files are fed back to linker via disk file instead of memory buffer.
      
        In this commit, lto_codegen_compile_parallel() simply calls
      lto_codegen_compile() to return a single object file. In the near future,
      this function is the entry point for compilation with partition. Linker can
      blindly call this function even if partition is turned off; in this case,
      compiler will return only one object file.
      
      llvm-svn: 189297
      a44362e4
  4. Aug 12, 2013
    • Shuxin Yang's avatar
      Revert r188188 and r188200. · 1826ae23
      Shuxin Yang authored
      In order to appease people (in Apple) who accuse me for committing "huge change" (?) without proper review. 
      
      Thank Eric for fixing a compile-warning. 
      
      llvm-svn: 188204
      1826ae23
    • Shuxin Yang's avatar
      Misc enhancements to LTO: · 76d082b5
      Shuxin Yang authored
        1. Add some helper classes for partitions. They are designed in a
           way such that the top-level LTO driver will not see much difference 
           with or without partitioning.
      
        2. Introduce work-dir. Now all intermediate files generated during 
           LTO phases will be saved under work-dir. User can specify the workdir
           via -lto-workdir=/path/to/dir. By default the work-dir will be 
           erased before linker exit. To keep the workdir, do -lto-keep, or -lto-keep=1.
      
          TODO: Erase the workdir, if the linker exit prematurely.  
            We are currently not able to remove directory on signal. The support 
            routines simply ignore directory.
      
        3. Add one new API lto_codegen_get_files_need_remove().
           Linker and LTO plugin will communicate via this API about which files
          (including directories) need to removed before linker exit.
      
      llvm-svn: 188188
      76d082b5
  5. Jan 10, 2013
  6. Dec 10, 2012
    • Bill Wendling's avatar
      Revert r169656. · 4a8fc8f2
      Bill Wendling authored
      The linker will call `lto_codegen_add_must_preserve_symbol' on all globals that
      should be kept around. The linker will pretend that a dylib is being created.
      <rdar://problem/12528059>
      
      llvm-svn: 169770
      4a8fc8f2
  7. Dec 08, 2012
    • Bill Wendling's avatar
      Add the `lto_codegen_set_export_dynamic' function. · 65a6ee11
      Bill Wendling authored
      This function sets the `_exportDynamic' ivar. When that's set, we export all
      symbols (e.g. we don't run the internalize pass). This is equivalent to the
      `--export-dynamic' linker flag in GNU land:
      
      --export-dynamic
        When creating a dynamically linked executable, add all symbols to the dynamic
        symbol table. The dynamic symbol table is the set of symbols which are visible
        from dynamic objects at run time. If you do not use this option, the dynamic
        symbol table will normally contain only those symbols which are referenced by
        some dynamic object mentioned in the link. If you use dlopen to load a dynamic
        object which needs to refer back to the symbols defined by the program, rather
        than some other dynamic object, then you will probably need to use this option
        when linking the program itself.
      
      The Darwin linker will support this via the `-export_dynamic' flag. We should
      modify clang to support this via the `-rdynamic' flag.
      
      llvm-svn: 169656
      65a6ee11
  8. Nov 24, 2012
    • Benjamin Kramer's avatar
      libLTO: Add a utility method to initialize the disassemblers. · 9bcb9226
      Benjamin Kramer authored
      Necessary to give disassembler users (like darwin's otool) a possibility to
      dlopen libLTO and still initialize the required LLVM bits. This used to go
      through libMCDisassembler but that's a gross layering violation, the MC layer
      can't pull in functions from the targets. Adding a function to libLTO is a bit
      of a hack but not worse than exposing other disassembler bits from libLTO.
      
      Fixes PR14362.
      
      llvm-svn: 168545
      9bcb9226
  9. Apr 16, 2012
  10. Apr 09, 2012
  11. Mar 31, 2012
  12. Mar 21, 2012
    • Gregory Szorc's avatar
      Organize LLVM C API docs into doxygen modules; add docs · 34c863a0
      Gregory Szorc authored
      This gives a lot of love to the docs for the C API. Like Clang's
      documentation, the C API is now organized into a Doxygen "module"
      (LLVMC). Each C header file is a child of the main module. Some modules
      (like Core) have a hierarchy of there own. The produced documentation is
      thus better organized (before everything was in one monolithic list).
      
      This patch also includes a lot of new documentation for APIs in Core.h.
      It doesn't document them all, but is better than none. Function docs are
      missing @param and @return annotation, but the documentation body now
      commonly provides help details (like the expected llvm::Value sub-type
      to expect).
      
      llvm-svn: 153157
      34c863a0
  13. Apr 15, 2011
  14. Mar 22, 2011
  15. Mar 17, 2011
  16. Feb 08, 2011
  17. Jan 07, 2011
  18. Nov 29, 2010
  19. Sep 27, 2010
  20. Aug 26, 2010
  21. Aug 25, 2010
  22. Aug 11, 2010
  23. Aug 10, 2010
  24. Aug 09, 2010
  25. Jul 12, 2010
  26. Jul 15, 2009
  27. Jul 02, 2009
  28. Jul 01, 2009
  29. Jun 04, 2009
  30. Apr 30, 2009
  31. Apr 24, 2009
  32. Feb 06, 2009
  33. Nov 29, 2008
  34. Jul 04, 2008
  35. May 04, 2008
Loading