Skip to content
  1. Oct 07, 2013
  2. Oct 05, 2013
  3. Oct 04, 2013
  4. Oct 03, 2013
  5. Oct 02, 2013
    • Benjamin Kramer's avatar
      Add newline at eof. · c12c7d0c
      Benjamin Kramer authored
      llvm-svn: 191857
      c12c7d0c
    • Richard Smith's avatar
      Pass the resolved lli-child-target executable name to execv, rather than · 2f1c87b0
      Richard Smith authored
      searching $PATH for it then blindly executing it from $PWD anyway.
      
      llvm-svn: 191856
      2f1c87b0
    • Andrew Kaylor's avatar
      Fix build problems with remote lli implementation · 74a61ed7
      Andrew Kaylor authored
      llvm-svn: 191848
      74a61ed7
    • Andrew Kaylor's avatar
      Clean up lli execution code · c87c347b
      Andrew Kaylor authored
      llvm-svn: 191845
      c87c347b
    • Andrew Kaylor's avatar
      Fixing compile warnings · 004e12ff
      Andrew Kaylor authored
      llvm-svn: 191844
      004e12ff
    • Andrew Kaylor's avatar
      Adding out-of-process execution support to lli. · c2ebf3f5
      Andrew Kaylor authored
      At this time only Unix-based systems are supported.  Windows has stubs and should re-route to the simulated mode.
      
      Thanks to Sriram Murali for contributions to this patch.
      
      llvm-svn: 191843
      c2ebf3f5
    • Chandler Carruth's avatar
      Remove the very substantial, largely unmaintained legacy PGO · ea564946
      Chandler Carruth authored
      infrastructure.
      
      This was essentially work toward PGO based on a design that had several
      flaws, partially dating from a time when LLVM had a different
      architecture, and with an effort to modernize it abandoned without being
      completed. Since then, it has bitrotted for several years further. The
      result is nearly unusable, and isn't helping any of the modern PGO
      efforts. Instead, it is getting in the way, adding confusion about PGO
      in LLVM and distracting everyone with maintenance on essentially dead
      code. Removing it paves the way for modern efforts around PGO.
      
      Among other effects, this removes the last of the runtime libraries from
      LLVM. Those are being developed in the separate 'compiler-rt' project
      now, with somewhat different licensing specifically more approriate for
      runtimes.
      
      llvm-svn: 191835
      ea564946
    • Chandler Carruth's avatar
      Tidy up this line of the Makefile before I start hacking on it. · d8c3e91e
      Chandler Carruth authored
      I really should sort it or do something more sustainable, but I couldn't
      work up the energy to do it... Sorry.
      
      llvm-svn: 191832
      d8c3e91e
    • Rafael Espindola's avatar
      Fix option parsing in the gold plugin. · efa02d53
      Rafael Espindola authored
      This was broken when options were moved up in r191680. No test because this is
      specific LLVMgold.so/libLTO.so.
      
      Patch by Tom Roeder!
      
      llvm-svn: 191829
      efa02d53
    • Rafael Espindola's avatar
      Add a -exported-symbol option to llvm-lto. · dafc53dd
      Rafael Espindola authored
      Patch by Tom Roeder.
      
      llvm-svn: 191825
      dafc53dd
    • Rafael Espindola's avatar
      Enable building LTO on WIN32. · d38f9af2
      Rafael Espindola authored
      Enable building the LTO library (.lib and.dll) and llvm-lto.exe on Windows with
      MSVC and Mingw as well as re-enabling the associated test.
      
      Patch by Greg Bedwell!
      
      llvm-svn: 191823
      d38f9af2
    • Filip Pizlo's avatar
      This threads SectionName through the allocateCodeSection/allocateDataSection... · 7aa695e0
      Filip Pizlo authored
      This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
      It's useful for the memory managers that are allocating a section to know what the name of the section is.  
      At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
      memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
      what each allocation is for.  This allows clients that supply their own memory managers to do this.  
      Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
      client.
      
      This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
      it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
      the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
      management C API).
      
      llvm-svn: 191804
      7aa695e0
  6. Oct 01, 2013
  7. Sep 30, 2013
  8. Sep 27, 2013
  9. Sep 26, 2013
  10. Sep 25, 2013
  11. Sep 20, 2013
  12. Sep 19, 2013
Loading