Skip to content
  1. Nov 09, 2016
  2. Nov 02, 2016
  3. Oct 28, 2016
  4. Oct 08, 2016
  5. Sep 11, 2016
  6. Aug 02, 2016
  7. Aug 01, 2016
    • Lang Hames's avatar
      [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol. · ad4a911f
      Lang Hames authored
      This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class
      that is capable of lazy materialization (i.e. the symbol definition needn't be
      emitted until the address is requested). This can be used to support common
      and weak symbols in the JIT (though this is not implemented in this patch).
      
      For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver.
      
      For space efficiency a new class, JITEvaluatedSymbol, is introduced that
      behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an
      address and symbol flags. Instances of JITEvaluatedSymbol can be used in
      symbol-tables to avoid paying the space cost of the materializer.
      
      llvm-svn: 277386
      ad4a911f
  8. Jun 29, 2016
  9. Jun 09, 2016
  10. Jun 08, 2016
  11. May 25, 2016
    • Lang Hames's avatar
      [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method when · bf9d1aa9
      Lang Hames authored
      searching for external symbols, and fall back to the SymbolResolver::findSymbol
      method if the former returns null.
      
      This makes RuntimeDyld behave more like a static linker: Symbol definitions
      from within the current module's "logical dylib" will be preferred to
      external definitions. We can build on this behavior in the future to properly
      support weak symbol handling.
      
      Custom symbol resolvers that override the findSymbolInLogicalDylib method may
      notice changes due to this patch. Clients who have not overridden this method
      should generally be unaffected, however users of the OrcMCJITReplacement class
      may notice changes.
      
      llvm-svn: 270716
      bf9d1aa9
  12. May 19, 2016
    • Rafael Espindola's avatar
      Delete Reloc::Default. · 8c34dd82
      Rafael Espindola authored
      Having an enum member named Default is quite confusing: Is it distinct
      from the others?
      
      This patch removes that member and instead uses Optional<Reloc> in
      places where we have a user input that still hasn't been maped to the
      default value, which is now clear has no be one of the remaining 3
      options.
      
      llvm-svn: 269988
      8c34dd82
  13. Apr 25, 2016
    • Lang Hames's avatar
      [ORC] Thread Error/Expected through the RPC library. · ef5a0ee2
      Lang Hames authored
      This replaces use of std::error_code and ErrorOr in the ORC RPC support library
      with Error and Expected. This required updating the OrcRemoteTarget API, Client,
      and server code, as well as updating the Orc C API.
      
      This patch also fixes several instances where Errors were dropped.
      
      llvm-svn: 267457
      ef5a0ee2
  14. Apr 18, 2016
    • Lang Hames's avatar
      [Orc] Re-commit r266581 with fixes for MSVC, and format cleanups. · 3fde652e
      Lang Hames authored
      Fixes:
      
      (1) Removes constexpr (unsupported in MSVC)
      (2) Move constructors (remove explicitly defaulted ones)
      (3) <future> - Add warning suppression for MSVC.
      
      llvm-svn: 266663
      3fde652e
    • Mehdi Amini's avatar
      lli: avoid global variables, use a local unique_ptr instead · a7de820a
      Mehdi Amini authored
      There was issue with order of destruction in some cases.
      
      From: Mehdi Amini <mehdi.amini@apple.com>
      llvm-svn: 266652
      a7de820a
    • Nico Weber's avatar
      Revert 266581 (and follow-up 266588), it doesn't build on Windows. · ca94d0ec
      Nico Weber authored
      Three problems:
      1. <future> can't be easily used.  If you must use it, see
         include/Support/ThreadPool.h for how.
      2. constexpr problems, even after 266588.
      3. Move assignment operators can't be defaulted in MSVC2013.
      
      llvm-svn: 266615
      ca94d0ec
    • Lang Hames's avatar
      [ORC] Generalize the ORC RPC utils to support RPC function return values and · 236cea74
      Lang Hames authored
      asynchronous call/handle. Also updates the ORC remote JIT API to use the new
      scheme.
      
      The previous version of the RPC tools only supported void functions, and
      required the user to manually call a paired function to return results. This
      patch replaces the Procedure typedef (which only supported void functions) with
      the Function typedef which supports return values, e.g.:
      
        Function<FooId, int32_t(std::string)> Foo;
      
      The RPC primitives and channel operations are also expanded. RPC channels must
      support four new operations: startSendMessage, endSendMessage,
      startRecieveMessage and endRecieveMessage, to handle channel locking. In
      addition, serialization support for tuples to RPCChannels is added to enable
      multiple return values.
      
      The RPC primitives are expanded from callAppend, call, expect and handle, to:
      
      appendCallAsync - Make an asynchronous call to the given function.
      
      callAsync - The same as appendCallAsync, but calls send on the channel when
                  done.
      
      callSTHandling - Blocking call for single-threaded code. Wraps a call to
                       callAsync then waits on the result, using a user-supplied
                       handler to handle any callbacks from the remote.
      
      callST - The same as callSTHandling, except that it doesn't handle
               callbacks - it expects the result to be the first return.
      
      expect and handle - as before.
      
      handleResponse - Handle a response from the remote.
      
      waitForResult - Wait for the response with the given sequence number to arrive.
      
      llvm-svn: 266581
      236cea74
  15. Apr 15, 2016
  16. Apr 14, 2016
  17. Apr 07, 2016
    • Kevin Enderby's avatar
      Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to... · 3fcdf6ae
      Kevin Enderby authored
      Thread Expected<...> up from createMachOObjectFile() to allow llvm-objdump to produce a real error message
      
      Produce the first specific error message for a malformed Mach-O file describing
      the problem instead of the generic message for object_error::parse_failed of
      "Invalid data was encountered while parsing the file”.  Many more good error
      messages will follow after this first one.
      
      This is built on Lang Hames’ great work of adding the ’Error' class for
      structured error handling and threading Error through MachOObjectFile
      construction.  And making createMachOObjectFile return Expected<...> .
      
      So to to get the error to the llvm-obdump tool, I changed the stack of
      these methods to also return Expected<...> :
      
        object::ObjectFile::createObjectFile()
        object::SymbolicFile::createSymbolicFile()
        object::createBinary()
      
      Then finally in ParseInputMachO() in MachODump.cpp the error can
      be reported and the specific error message can be printed in llvm-objdump
      and can be seen in the existing test case for the existing malformed binary
      but with the updated error message.
      
      Converting these interfaces to Expected<> from ErrorOr<> does involve
      touching a number of places. To contain the changes for now use of
      errorToErrorCode() and errorOrToExpected() are used where the callers
      are yet to be converted.
      
      Also there some were bugs in the existing code that did not deal with the
      old ErrorOr<> return values.  So now with Expected<> since they must be
      checked and the error handled, I added a TODO and a comment:
      “// TODO: Actually report errors helpfully” and a call something like
      consumeError(ObjOrErr.takeError()) so the buggy code will not crash
      since needed to deal with the Error.
      
      Note there is one fix also needed to lld/COFF/InputFiles.cpp that goes along
      with this that I will commit right after this.  So expect lld not to built
      after this commit and before the next one.
      
      llvm-svn: 265606
      3fcdf6ae
  18. Jan 17, 2016
  19. Jan 15, 2016
  20. Jan 11, 2016
  21. Dec 18, 2015
    • Rafael Espindola's avatar
      Drop materializeAllPermanently. · c4a03483
      Rafael Espindola authored
      This inlines materializeAll into the only caller
      (materializeAllPermanently) and renames materializeAllPermanently to
      just materializeAll.
      
      llvm-svn: 256024
      c4a03483
  22. Jul 15, 2015
  23. Jun 09, 2015
  24. May 12, 2015
    • Eric Christopher's avatar
      Migrate existing backends that care about software floating point · 824f42f2
      Eric Christopher authored
      to use the information in the module rather than TargetOptions.
      
      We've had and clang has used the use-soft-float attribute for some
      time now so have the backends set a subtarget feature based on
      a particular function now that subtargets are created based on
      functions and function attributes.
      
      For the one middle end soft float check go ahead and create
      an overloadable TargetLowering::useSoftFloat function that
      just checks the TargetSubtargetInfo in all cases.
      
      Also remove the command line option that hard codes whether or
      not soft-float is set by using the attribute for all of the
      target specific test cases - for the generic just go ahead and
      add the attribute in the one case that showed up.
      
      llvm-svn: 237079
      824f42f2
  25. Apr 19, 2015
  26. Apr 11, 2015
  27. Mar 25, 2015
    • Lang Hames's avatar
      [Orc][lli] Add a very simple Orc-based lazy JIT to lli. · 9528bbaa
      Lang Hames authored
      This ensures that we're building and testing the CompileOnDemand layer, at least
      in a basic way.
      
      Currently x86-64 only, and with limited to no library calls enabled (depending
      on host platform). Patches welcome. ;)
      
      To enable access to the lazy JIT, this patch replaces the '-use-orcmcjit' lli
      option with a new option:
      '-jit-kind={ mcjit | orc-mcjit | orc-lazy }'.
      
      All regression tests are updated to use the new option, and one trivial test of
      the new lazy JIT is added.
      
      llvm-svn: 233182
      9528bbaa
  28. Mar 23, 2015
  29. Feb 26, 2015
  30. Jan 23, 2015
    • Lang Hames's avatar
      [Orc] New JIT APIs. · 93de2a12
      Lang Hames authored
      This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to
      cleanly support a wider range of JIT use cases in LLVM, and encourage the
      development and contribution of re-usable infrastructure for LLVM JIT use-cases.
      
      These APIs are intended to live alongside the MCJIT APIs, and should not affect
      existing clients.
      
      Included in this patch:
      
      1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of
         components for building JIT infrastructure.
         Implementation code for these headers lives in lib/ExecutionEngine/Orc.
      
      2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the
         new components.
      
      3) Minor changes to RTDyldMemoryManager needed to support the new components.
         These changes should not impact existing clients.
      
      4) A new flag for lli, -use-orcmcjit, which will cause lli to use the
         OrcMCJITReplacement class as its underlying execution engine, rather than
         MCJIT itself.
      
      Tests to follow shortly.
      
      Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher,
      Justin Bogner, and Jim Grosbach for extensive feedback and discussion.
      
      llvm-svn: 226940
      93de2a12
  31. Jan 22, 2015
    • Chris Bieneman's avatar
      Assigning and copying command line option objects shouldn't be allowed. · e71fb5ce
      Chris Bieneman authored
      Summary:
      The default copy and assignment operators for these objects probably don't actually do what the clients intend, so they should be deleted.
      
      Places using the assignment operator to set the value of an option should cast to the option's data type first to call into the override for operator=. Places using the copy constructor just need to be changed to not copy (i.e. passing by const reference instead of value).
      
      Reviewers: dexonsmith, chandlerc
      
      Subscribers: llvm-commits
      
      Differential Revision: http://reviews.llvm.org/D7114
      
      llvm-svn: 226762
      e71fb5ce
  32. Dec 03, 2014
  33. Nov 29, 2014
  34. Sep 23, 2014
  35. Sep 03, 2014
Loading