llvm-svn: 268846

This enables lazy JITing on Windows x86-64.

Patch by David. Thanks David!

llvm-svn: 268845

llvm-svn: 267512

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

Fixes:

(1) Removes constexpr (unsupported in MSVC)
(2) Move constructors (remove explicitly defaulted ones)
(3) <future> - Add warning suppression for MSVC.

llvm-svn: 266663

There was issue with order of destruction in some cases.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266652

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

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

lli.cpp: Appease some builders. There might be ownership issues between LLVMContext and ExecutionEngine. Investigating.

llvm-svn: 266441

At the same time, fixes InstructionsTest::CastInst unittest: yes
you can leave the IR in an invalid state and exit when you don't
destroy the context (like the global one), no longer now.

This is the first part of http://reviews.llvm.org/D19094

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266379

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

This patch adds a new class, OrcI386, which contains the hooks needed to
support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT
re-entry code uses the FXSAVE/FXRSTOR instructions).

Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and
regression and unit tests are enabled for this architecture.

llvm-svn: 260338

Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi

Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark

Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D16471

llvm-svn: 258861

review of r257343.

Thanks Dave!

llvm-svn: 258002

This class is in the LLI tool, and isn't subclassed.

llvm-svn: 257937

llvm-svn: 257857

classes.

OrcRemoteTargetClient::RCMemoryManager will now register EH frames with the
server automatically. This allows remote-execution of code that uses exceptions.

llvm-svn: 257816

llvm-svn: 257430

llvm-svn: 257410

llvm-svn: 257391

llvm-svn: 257360

RemoteTarget.cpp was removed in r257343.

llvm-svn: 257351

The new ORC remote-JITing support provides a superset of the old code's
functionality, so we can replace the old stuff. As a bonus, a couple of
previously XFAILed tests have started passing.

llvm-svn: 257343

the upcoming remote-target support classes.

llvm-svn: 257302

Previously the CompileOnDemand layer was hard-coded to use a new
SectionMemoryManager for each function when it was called.

llvm-svn: 257265

This inlines materializeAll into the only caller
(materializeAllPermanently) and renames materializeAllPermanently to
just materializeAll.

llvm-svn: 256024

No functional change.

llvm-svn: 254885

This class is turning into a useful interface, rather than an implementation
detail, so I'm dropping the 'Base' suffix.

No functional change.

llvm-svn: 254693

Fixed warnings are: modernize-use-override, modernize-use-nullptr and modernize-redundant-void-arg.

Differential revision: http://reviews.llvm.org/D14312

llvm-svn: 252087

This reverts commit r251937.

The test was updated to the new API, bring the API back.

llvm-svn: 251944

This reverts commit r251933.

It broke the build of examples/Kaleidoscope/Orc/fully_lazy/toy.cpp.

llvm-svn: 251937

Bypassing LLVM for this has a number of benefits:

1) Laziness support becomes asm-syntax agnostic (previously lazy jitting didn't
   work on Windows as the resolver block was in Darwin asm).

2) For cross-process JITs, it allows resolver blocks and trampolines to be
   emitted directly in the target process, reducing cross process traffic.

3) It should be marginally faster.

llvm-svn: 251933

memory, rather than representing the stubs in IR. Update the CompileOnDemand
layer to use this functionality.

Directly emitting stubs is much cheaper than building them in IR and codegen'ing
them (see below). It also plays well with remote JITing - stubs can be emitted
directly in the target process, rather than having to send them over the wire.

The downsides are:

(1) Care must be taken when resolving symbols, as stub symbols are held in a
    separate symbol table. This is only a problem for layer writers and other
    people using this API directly. The CompileOnDemand layer hides this detail.

(2) Aliases of function stubs can't be symbolic any more (since there's no
    symbol definition in IR), but must be converted into a constant pointer
    expression. This means that modules containing aliases of stubs cannot be
    cached. In practice this is unlikely to be a problem: There's no benefit to
    caching such a module anyway.

On balance I think the extra performance is more than worth the trade-offs: In a
simple stress test with 10000 dummy functions requiring stubs and a single
executed "hello world" main function, directly emitting stubs reduced user time
for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct
emission).

llvm-svn: 250712

Previously the CompileOnDemand layer always created single-function partitions.
In theory this new API allows for more interesting partitions, though this has
not been well tested yet.

llvm-svn: 249623

Set the correct one using the TargetMachine instead.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243664

Summary:
Replace getDataLayout() with a createDataLayout() method to make
explicit that it is intended to create a DataLayout only and not
accessing it for other purpose.

This change is the last of a series of commits dedicated to have a
single DataLayout during compilation by using always the one owned
by the module.

Reviewers: echristo

Subscribers: jholewinski, llvm-commits, rafael, yaron.keren

Differential Revision: http://reviews.llvm.org/D11103

(cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243114

This reverts commit 0f720d984f419c747709462f7476dff962c0bc41.

It breaks clang too badly, I need to prepare a proper patch for clang
first.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243089

Summary:
Replace getDataLayout() with a createDataLayout() method to make
explicit that it is intended to create a DataLayout only and not
accessing it for other purpose.

This change is the last of a series of commits dedicated to have a
single DataLayout during compilation by using always the one owned
by the module.

Reviewers: echristo

Subscribers: jholewinski, llvm-commits, rafael, yaron.keren

Differential Revision: http://reviews.llvm.org/D11103

(cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea)

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 243083

llvm-svn: 242334

We only need to pass in a DataLayout when mangling a raw string, not when
constructing the mangler.

llvm-svn: 240405