Skip to content
  1. Mar 15, 2012
  2. Mar 14, 2012
  3. Mar 13, 2012
  4. Jan 16, 2012
    • Jim Grosbach's avatar
      MCJIT support for non-function sections. · eff0a40d
      Jim Grosbach authored
      Move to a by-section allocation and relocation scheme. This allows
      better support for sections which do not contain externally visible
      symbols.
      
      Flesh out the relocation address vs. local storage address separation a
      bit more as well. Remote process JITs use this to tell the relocation
      resolution code where the code will live when it executes.
      
      The startFunctionBody/endFunctionBody interfaces to the JIT and the
      memory manager are deprecated. They'll stick around for as long as the
      old JIT does, but the MCJIT doesn't use them anymore.
      
      llvm-svn: 148258
      eff0a40d
  5. Dec 02, 2011
  6. Nov 09, 2011
  7. Oct 16, 2011
  8. Sep 03, 2011
  9. Aug 27, 2011
  10. Aug 24, 2011
  11. Jul 27, 2011
  12. Jul 18, 2011
  13. Jul 12, 2011
    • Jay Foad's avatar
      Second attempt at de-constifying LLVM Types in FunctionType::get(), · b804a2b7
      Jay Foad authored
      StructType::get() and TargetData::getIntPtrType().
      
      llvm-svn: 134982
      b804a2b7
    • Bill Wendling's avatar
      Revert r134893 and r134888 (and related patches in other trees). It was causing · a78cd228
      Bill Wendling authored
      an assert on Darwin llvm-gcc builds.
      
      Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, li\
      ne 2067.
      etc.
      
      http://smooshlab.apple.com:8013/builders/llvm-gcc-i386-darwin9-RA/builds/2354
      
      --- Reverse-merging r134893 into '.':
      U    include/llvm/Target/TargetData.h
      U    include/llvm/DerivedTypes.h
      U    tools/bugpoint/ExtractFunction.cpp
      U    unittests/Support/TypeBuilderTest.cpp
      U    lib/Target/ARM/ARMGlobalMerge.cpp
      U    lib/Target/TargetData.cpp
      U    lib/VMCore/Constants.cpp
      U    lib/VMCore/Type.cpp
      U    lib/VMCore/Core.cpp
      U    lib/Transforms/Utils/CodeExtractor.cpp
      U    lib/Transforms/Instrumentation/ProfilingUtils.cpp
      U    lib/Transforms/IPO/DeadArgumentElimination.cpp
      U    lib/CodeGen/SjLjEHPrepare.cpp
      --- Reverse-merging r134888 into '.':
      G    include/llvm/DerivedTypes.h
      U    include/llvm/Support/TypeBuilder.h
      U    include/llvm/Intrinsics.h
      U    unittests/Analysis/ScalarEvolutionTest.cpp
      U    unittests/ExecutionEngine/JIT/JITTest.cpp
      U    unittests/ExecutionEngine/JIT/JITMemoryManagerTest.cpp
      U    unittests/VMCore/PassManagerTest.cpp
      G    unittests/Support/TypeBuilderTest.cpp
      U    lib/Target/MBlaze/MBlazeIntrinsicInfo.cpp
      U    lib/Target/Blackfin/BlackfinIntrinsicInfo.cpp
      U    lib/VMCore/IRBuilder.cpp
      G    lib/VMCore/Type.cpp
      U    lib/VMCore/Function.cpp
      G    lib/VMCore/Core.cpp
      U    lib/VMCore/Module.cpp
      U    lib/AsmParser/LLParser.cpp
      U    lib/Transforms/Utils/CloneFunction.cpp
      G    lib/Transforms/Utils/CodeExtractor.cpp
      U    lib/Transforms/Utils/InlineFunction.cpp
      U    lib/Transforms/Instrumentation/GCOVProfiling.cpp
      U    lib/Transforms/Scalar/ObjCARC.cpp
      U    lib/Transforms/Scalar/SimplifyLibCalls.cpp
      U    lib/Transforms/Scalar/MemCpyOptimizer.cpp
      G    lib/Transforms/IPO/DeadArgumentElimination.cpp
      U    lib/Transforms/IPO/ArgumentPromotion.cpp
      U    lib/Transforms/InstCombine/InstCombineCompares.cpp
      U    lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
      U    lib/Transforms/InstCombine/InstCombineCalls.cpp
      U    lib/CodeGen/DwarfEHPrepare.cpp
      U    lib/CodeGen/IntrinsicLowering.cpp
      U    lib/Bitcode/Reader/BitcodeReader.cpp
      
      llvm-svn: 134949
      a78cd228
  14. Jul 11, 2011
  15. Jun 16, 2011
  16. Nov 19, 2010
  17. Jul 22, 2010
    • Chris Lattner's avatar
      missed a use of SizeRequired. · eb4e3dce
      Chris Lattner authored
      llvm-svn: 109172
      eb4e3dce
    • Chris Lattner's avatar
      instead of migrating it to the MC instruction encoder, just · 083be4d3
      Chris Lattner authored
      rip out the implementation of X86InstrInfo::GetInstSizeInBytes.
      The code being ripped out just implemented a copy and hacked up
      version of the (old) instruction encoder, and is buggy and 
      terrible in other ways.  Since "GetInstSizeInBytes" is really 
      only there to support the JIT's "NeedsExactSize" hook (which
      noone is using), just rip out the code.  I will rip out the
      NeedsExactSize hook next.
      
      This resolves rdar://7617809 - switch X86InstrInfo::GetInstSizeInBytes to use X86MCCodeEmitter
      
      llvm-svn: 109149
      083be4d3
  18. Apr 13, 2010
  19. Apr 06, 2010
  20. Mar 04, 2010
  21. Feb 11, 2010
  22. Jan 27, 2010
    • Jeffrey Yasskin's avatar
      Kill ModuleProvider and ghost linkage by inverting the relationship between · 091217be
      Jeffrey Yasskin authored
      Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
      GlobalValues now, and doesn't provide modules, it's renamed to
      "GVMaterializer". Code that used to need a ModuleProvider to materialize
      Functions can now materialize the Functions directly. Functions no longer use a
      magic linkage to record that they're materializable; they simply ask the
      GVMaterializer.
      
      Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
      the functions that refer to it. Instead, because Module now exposes the same
      functionality ModuleProvider used to, we store a Module* in any
      LLVMModuleProviderRef and translate in the wrapper methods.  The bindings to
      other languages still use the ModuleProvider concept.  It would probably be
      worth some time to update them to follow the C++ more closely, but I don't
      intend to do it.
      
      Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
      
      llvm-svn: 94686
      091217be
    • Jeffrey Yasskin's avatar
      Roll r94484 (avoiding RTTI problems in tests) forward again in a way that isn't · 6d7deae2
      Jeffrey Yasskin authored
      broken by setting CXXFLAGS on the command line.
      
      llvm-svn: 94619
      6d7deae2
  23. Jan 26, 2010
  24. Jan 22, 2010
    • Chris Lattner's avatar
      Stop building RTTI information for *most* llvm libraries. Notable · 7ba0661f
      Chris Lattner authored
      missing ones are libsupport, libsystem and libvmcore.  libvmcore is
      currently blocked on bugpoint, which uses EH.  Once it stops using
      EH, we can switch it off.
      
      This #if 0's out 3 unit tests, because gtest requires RTTI information.
      Suggestions welcome on how to fix this.
      
      llvm-svn: 94164
      7ba0661f
  25. Dec 23, 2009
  26. Dec 17, 2009
  27. Dec 13, 2009
  28. Dec 12, 2009
  29. Nov 24, 2009
  30. Nov 17, 2009
  31. Nov 16, 2009
    • Jeffrey Yasskin's avatar
      Make X86-64 in the Large model always emit 64-bit calls. · 10d3604a
      Jeffrey Yasskin authored
      The large code model is documented at
      http://www.x86-64.org/documentation/abi.pdf and says that calls should
      assume their target doesn't live within the 32-bit pc-relative offset
      that fits in the call instruction.
      
      To do this, we turn off the global-address->target-global-address
      conversion in X86TargetLowering::LowerCall(). The first attempt at
      this broke the lazy JIT because it can separate the movabs(imm->reg)
      from the actual call instruction. The lazy JIT receives the address of
      the movabs as a relocation and needs to record the return address from
      the call; and then when that call happens, it needs to patch the
      movabs with the newly-compiled target. We could thread the call
      instruction into the relocation and record the movabs<->call mapping
      explicitly, but that seems to require at least as much new
      complication in the code generator as this change.
      
      To fix this, we make lazy functions _always_ go through a call
      stub. You'd think we'd only have to force lazy calls through a stub on
      difficult platforms, but that turns out to break indirect calls
      through a function pointer. The right fix for that is to distinguish
      between calls and address-of operations on uncompiled functions, but
      that's complex enough to leave for someone else to do.
      
      Another attempt at this defined a new CALL64i pseudo-instruction,
      which expanded to a 2-instruction sequence in the assembly output and
      was special-cased in the X86CodeEmitter's emitInstruction()
      function. That broke indirect calls in the same way as above.
      
      This patch also removes a hack forcing Darwin to the small code model.
      Without far-call-stubs, the small code model requires things of the
      JITMemoryManager that the DefaultJITMemoryManager can't provide.
      
      Thanks to echristo for lots of testing!
      
      llvm-svn: 88984
      10d3604a
Loading