review of r257343.

Thanks Dave!

llvm-svn: 258002

llvm-svn: 257857

llvm-svn: 257391

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

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

llvm-svn: 256024

llvm-svn: 242334

No test case - this only affects generated code performance.

llvm-svn: 239383

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

not used anywhere in llvm.

llvm-svn: 235265

The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' \
    -j=32 -fix -format

http://reviews.llvm.org/D8925

llvm-svn: 234679

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

NFC.

llvm-svn: 232976

llvm-svn: 230599

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

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

llvm-svn: 223183

llvm-svn: 222945

llvm-svn: 218318

This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.

http://llvm.org/PR20848

llvm-svn: 218316

Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reinstates commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 216982

llvm-svn: 216583

Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.

llvm-svn: 216484

llvm-svn: 216466

Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.

A create static method would be even better, but this patch is already a bit too
big.

llvm-svn: 216393

llvm-svn: 216071

Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
  This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
  for convenience functions that take a filename and return both the
  buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

llvm-svn: 216002

llvm-svn: 215967

llvm-svn: 215566

be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.

Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reverts commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 215154

I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.

Thanks to Lang Hames for making MCJIT a good replacement!

llvm-svn: 215111

Also fix the error handling. No testcaes, issue found by inspection.

Thanks to David Blaikie for the suggestion.

llvm-svn: 214535

llvm-svn: 214533

llvm-svn: 214377

llvm-svn: 212405

Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.

llvm-svn: 211595

llvm-svn: 210876

This should make sure that most new uses use the std prefix.

llvm-svn: 210835

This starts in MCJIT::getSymbolAddress where the
unique_ptr<object::Binary> is release()d and (after a cast) passed to a
single caller, MCJIT::addObjectFile.

addObjectFile calls RuntimeDyld::loadObject.
RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile

And the pointer is never owned at this point. I say this point, because
the alternative codepath, RuntimeDyldMachO::createObjectFile certainly
does take ownership, so this seemed like a good hint that this was a/the
right place to take ownership.

llvm-svn: 207580

llvm-svn: 207176

definition below all of the header #include lines, tools edition.

llvm-svn: 206848