Skip to content
  1. Dec 28, 2013
  2. Dec 12, 2013
  3. Dec 10, 2013
  4. Oct 16, 2013
    • Rafael Espindola's avatar
      Assert on duplicate registration. Don't depend on function pointer equality. · 40a3d018
      Rafael Espindola authored
      Before this patch we would assert when building llvm as multiple shared
      libraries (cmake's BUILD_SHARED_LIBS). The problem was the line
      
      if (T.AsmStreamerCtorFn == Target::createDefaultAsmStreamer)
      
      which returns false because of -fvisibility-inlines-hidden. It is easy
      to fix just this one case, but I decided to try to also make the
      registration more strict. It looks like the old logic for ignoring
      followup registration was just a temporary hack that outlived its
      usefulness.
      
      This patch converts the ifs to asserts, fixes the few cases that were
      registering twice and makes sure all the asserts compare with null.
      
      Thanks for Joerg for reporting the problem and reviewing the patch.
      
      llvm-svn: 192803
      40a3d018
  5. Oct 02, 2013
    • 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. Jul 27, 2013
  7. Jul 26, 2013
    • Bill Schmidt's avatar
      [PowerPC] Improve consistency in use of __ppc__, __powerpc__, etc. · 419f7c23
      Bill Schmidt authored
      Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for
      all PowerPC targets, whether 32- or 64-bit.  They will both implicitly
      define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not
      for 32-bit targets.  We cannot be sure that all other possible
      compilers used to compile Clang/LLVM define both __ppc__ and
      __powerpc__, for example, so it is best to check for both when relying
      on either inside the Clang/LLVM code base.
      
      This patch makes sure we always check for both variants.  In addition,
      it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp.
      (At least one of __ppc__ and __powerpc__ should always be defined when
      compiling for a PowerPC target, no matter which compiler is used, so
      testing for them is unnecessary.)
      
      There are some places in the compiler that check for other variants,
      like __POWERPC__ and _POWER, and I have left those in place.  There is
      no need to add them elsewhere.  This seems to be in Apple-specific
      code, and I won't take a chance on breaking it.
      
      There is no intended change in behavior; thus, no test cases are
      added.
      
      llvm-svn: 187248
      419f7c23
  8. Jul 02, 2013
  9. May 21, 2013
    • Ulrich Weigand's avatar
      · 7c81c7c6
      Ulrich Weigand authored
      Alternative fix for problem addressed in r182233
      
      Revision r182233 partially reverted the change in r181200 to simplify
      JIT unif test #ifdefs, because that change caused a link error on some
      host operating systems where the export list requires the following
      symbols to be defined:
      
       JITTest_AvailableExternallyFunction
       JITTest_AvailableExternallyGlobal
      
      As discussed on the list, the commit reverts r182233 (and re-installs
      the full r181200 change), and instead fixes the link problem by moving
      those two symbols to the top of the file and unconditionally defining
      them.
      
      llvm-svn: 182367
      7c81c7c6
  10. May 20, 2013
    • Bob Wilson's avatar
      Partially revert change in r181200 that tried to simplify JIT unit test #ifdefs. · 29699c63
      Bob Wilson authored
      The export list for this test requires the following symbols to be available:
        JITTest_AvailableExternallyFunction
        JITTest_AvailableExternallyGlobal
      The change in r181200 commented them out, which caused the test to fail to
      link, at least on Darwin. I have only reverted the change for arm, since I
      can't test the other targets and since it sounds like that change was fixing
      real problems for those other targets. It should be possible to rearrange the
      code to keep those definitions outside the #ifdefs, but that should be done by
      someone who can reproduce the problems that r181200 was trying to fix.
      
      llvm-svn: 182233
      29699c63
  11. May 17, 2013
  12. May 07, 2013
  13. May 06, 2013
    • Ulrich Weigand's avatar
      · 80435baa
      Ulrich Weigand authored
      [SystemZ] Set up JIT/MCJIT test cases
      
      This patch adds the necessary configuration bits and #ifdef's to set up
      the JIT/MCJIT test cases for SystemZ.  Like other recent targets, we do
      fully support MCJIT, but do not support the old JIT at all.  Set up the
      lit config files accordingly, and disable old-JIT unit tests.
      
      Patch by Richard Sandiford.
      
      llvm-svn: 181207
      80435baa
    • Ulrich Weigand's avatar
      · f1c30045
      Ulrich Weigand authored
      Simplify JIT unit test #ifdefs
      
      Several platforms need to disable all old-JIT unit tests, since they only
      support the new MCJIT.  This currently done via #ifdef'ing out those tests
      in the ExecutionEngine/JIT/*.cpp files.  As those #ifdef's have grown
      historically, we now have a number of repeated directives which -in total-
      cover nearly the whole file, but leave a couple of helper functions out.
      When building the tests with clang itself, those helper functions now
      cause spurious "unused function" warnings.
      
      To fix those warnings, and also to remove the duplicate #ifdef conditions
      and make it easier to disable the tests for a new target, this patch
      consolidates the #ifdefs into a single one per file, which covers all
      the tests including all helper routines.
      
      Tested on PowerPC and SystemZ.
      
      llvm-svn: 181200
      f1c30045
  14. Apr 04, 2013
  15. Jan 28, 2013
  16. Jan 11, 2013
  17. Jan 02, 2013
    • Chandler Carruth's avatar
      Move all of the header files which are involved in modelling the LLVM IR · 9fb823bb
      Chandler Carruth authored
      into their new header subdirectory: include/llvm/IR. This matches the
      directory structure of lib, and begins to correct a long standing point
      of file layout clutter in LLVM.
      
      There are still more header files to move here, but I wanted to handle
      them in separate commits to make tracking what files make sense at each
      layer easier.
      
      The only really questionable files here are the target intrinsic
      tablegen files. But that's a battle I'd rather not fight today.
      
      I've updated both CMake and Makefile build systems (I think, and my
      tests think, but I may have missed something).
      
      I've also re-sorted the includes throughout the project. I'll be
      committing updates to Clang, DragonEgg, and Polly momentarily.
      
      llvm-svn: 171366
      9fb823bb
  18. Dec 04, 2012
  19. Nov 16, 2012
  20. Oct 31, 2012
    • Ulrich Weigand's avatar
      Disable all old-JIT unit tests on PowerPC. · 1caa6f95
      Ulrich Weigand authored
      These tests were all failing since the old JIT doesn't work
      for PowerPC (any more), and there are no plans to attempt to
      fix it again (instead, work focuses on MCJIT).
      
      llvm-svn: 167133
      1caa6f95
  21. Oct 18, 2012
    • Bob Wilson's avatar
      Use an export list when building JIT unittests. <rdar://problem/12473675> · 0f295dec
      Bob Wilson authored
      When building with LTO, the internalize pass is hiding some global symbols
      that are necessary for the JIT unittests. It seems like that may be a bug in
      LTO to do that by default, but until that gets fixed, this change makes sure
      that we export the necessary symbols for the tests to pass.
      
      llvm-svn: 166220
      0f295dec
  22. Oct 17, 2012
  23. Oct 12, 2012
  24. Oct 08, 2012
    • James Molloy's avatar
      Some regression tests which are testing the old jit and are exercising... · 0ae35af5
      James Molloy authored
      Some regression tests which are testing the old jit and are exercising functionality which is both known to be broken and not expected to be fixed in the old jit. To remove these from the regression test output, I've marked them XFAIL (for lit tests) and ifdef'd them out (unit tests). These modifications remove the last long-standing regression test failures from the buildbots (though updating the triple to reflect new ubuntu configuration has temporarily caused some new failures). Tested on x86-64 and ARM Linux.
      
      Patch by David Tweed!
      
      llvm-svn: 165390
      0ae35af5
  25. Sep 28, 2012
  26. Sep 27, 2012
  27. Aug 01, 2012
  28. Jul 16, 2012
    • Chandler Carruth's avatar
      Move llvm/Support/TypeBuilder.h -> llvm/TypeBuilder.h. This completes · 36e2ecf5
      Chandler Carruth authored
      the move of *Builder classes into the Core library.
      
      No uses of this builder in Clang or DragonEgg I could find.
      
      If there is a desire to have an IR-building-support library that
      contains all of these builders, that can be easily added, but currently
      it seems likely that these add no real overhead to VMCore.
      
      llvm-svn: 160243
      36e2ecf5
  29. Jun 29, 2012
    • Chandler Carruth's avatar
      Move llvm/Support/IRBuilder.h -> llvm/IRBuilder.h · aafe0918
      Chandler Carruth authored
      This was always part of the VMCore library out of necessity -- it deals
      entirely in the IR. The .cpp file in fact was already part of the VMCore
      library. This is just a mechanical move.
      
      I've tried to go through and re-apply the coding standard's preferred
      header sort, but at 40-ish files, I may have gotten some wrong. Please
      let me know if so.
      
      I'll be committing the corresponding updates to Clang and Polly, and
      Duncan has DragonEgg.
      
      Thanks to Bill and Eric for giving the green light for this bit of cleanup.
      
      llvm-svn: 159421
      aafe0918
    • Bill Wendling's avatar
      The DIBuilder class is just a wrapper around debug info creation · f799efde
      Bill Wendling authored
      (a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore
      instead.
      
      llvm-svn: 159414
      f799efde
  30. Jun 28, 2012
  31. Jun 22, 2012
  32. Jun 21, 2012
Loading