Commit Graph

5499 Commits

Author SHA1 Message Date
Chandler Carruth
276f405407 [multiversion] Implement the old pass manager's TTI wrapper pass in
terms of the new pass manager's TargetIRAnalysis.

Yep, this is one of the nicer bits of the new pass manager's design.
Passes can in many cases operate in a vacuum and so we can just nest
things when convenient. This is particularly convenient here as I can
now consolidate all of the TargetMachine logic on this analysis.

The most important change here is that this pushes the function we need
TTI for all the way into the TargetMachine, and re-creates the TTI
object for each function rather than re-using it for each function.
We're now prepared to teach the targets to produce function-specific TTI
objects with specific subtargets cached, etc.

One piece of feedback I'd love here is whether its worth renaming any of
this stuff. None of the names really seem that awesome to me at this
point, but TargetTransformInfoWrapperPass is particularly ... odd.
TargetIRAnalysisWrapper might make more sense. I would want to do that
rename separately anyways, but let me know what you think.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227731 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 12:26:09 +00:00
Chandler Carruth
9a941b2028 [PM] Port SimplifyCFG to the new pass manager.
This should be sufficient to replace the initial (minor) function pass
pipeline in Clang with the new pass manager. I'll probably add an (off
by default) flag to do that just to ensure we can get extra testing.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227726 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 11:34:21 +00:00
Chandler Carruth
80c55f265d [PM] Port EarlyCSE to the new pass manager.
I've added RUN lines both to the basic test for EarlyCSE and the
target-specific test, as this serves as a nice test that the TTI layer
in the new pass manager is in fact working well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227725 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 10:51:23 +00:00
Chandler Carruth
7724e8efa2 [PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to
produce it.

This adds a function to the TargetMachine that produces this analysis
via a callback for each function. This in turn faves the way to produce
a *different* TTI per-function with the correct subtarget cached.

I've also done the necessary wiring in the opt tool to thread the target
machine down and make it available to the pass registry so that we can
construct this analysis from a target machine when available.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227721 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 10:11:22 +00:00
Chandler Carruth
581ef38430 [PM] Refactor the analysis registration and pass pipeline parsing to
live in a class.

While this isn't really significant right now, I need to expose some
state to the pass construction expressions, and making them get
evaluated within a class context is a nice way to collect members that
they may need to access.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227715 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-01 07:40:05 +00:00
Chandler Carruth
1937233a22 [PM] Switch the TargetMachine interface from accepting a pass manager
base which it adds a single analysis pass to, to instead return the type
erased TargetTransformInfo object constructed for that TargetMachine.

This removes all of the pass variants for TTI. There is now a single TTI
*pass* in the Analysis layer. All of the Analysis <-> Target
communication is through the TTI's type erased interface itself. While
the diff is large here, it is nothing more that code motion to make
types available in a header file for use in a different source file
within each target.

I've tried to keep all the doxygen comments and file boilerplate in line
with this move, but let me know if I missed anything.

With this in place, the next step to making TTI work with the new pass
manager is to introduce a really simple new-style analysis that produces
a TTI object via a callback into this routine on the target machine.
Once we have that, we'll have the building blocks necessary to accept
a function argument as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227685 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 11:17:59 +00:00
Chandler Carruth
a6a87b595d [PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.

The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.

I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.

There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.

The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.

Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.

The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]

Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:

1) Improving the TargetMachine interface by having it directly return
   a TTI object. Because we have a non-pass object with value semantics
   and an internal type erasure mechanism, we can narrow the interface
   of the TargetMachine to *just* do what we need: build and return
   a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
   This will include splitting off a minimal form of it which is
   sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
   target machine for each function. This may actually be done as part
   of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
   easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
   easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
   just a bit messy and exacerbating the complexity of implementing
   the TTI in each target.

Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
Kevin Enderby
0602444f70 Add the -section option to llvm-objdump used with -macho that takes the argument
segname,sectname to specify a Mach-O section to print.  The printing is based on
the section type or section attributes.

The printing of the module initialization and termination section types is printed
with this change.  Printing of other section types will be added next.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227649 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 00:37:11 +00:00
Alexey Samsonov
9b8adaf3b2 Fixup gold-plugin after r227576.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227599 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 19:14:04 +00:00
Zachary Turner
728d12e435 Fix lli after the DebugInfo move.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227594 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 18:42:03 +00:00
Zachary Turner
de20f59a2a Really really don't build llvm-pdbdump on MSVC < 2013.
I thought it was enough to just not add the tool subdirectory,
but apparently I need to explicitly mark it ignore.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227587 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 18:08:05 +00:00
Zachary Turner
50418a0ac4 Move DebugInfo to DebugInfo/DWARF.
In preparation for adding PDB support to LLVM, this moves the
DWARF parsing code to its own subdirectory under DebugInfo, and
renames LLVMDebugInfo to LLVMDebugInfoDWARF.

This is purely a mechanical / build system change.

Differential Revision: http://reviews.llvm.org/D7269
Reviewed by: Eric Christopher

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227586 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 18:07:45 +00:00
Akira Hatanaka
31db3d6d62 [llvm-lto] Add a line for setting LTOCodeGenerator's CPU string from command
line.

This is needed for a test case I plan to commit later.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227532 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 01:14:28 +00:00
Zachary Turner
3a5a587abf Disable compilation of llvm-pdbdump for versions of MSVC < 2013.
Certain aspects of llvm-pdbdump require language support only present in
MSVC 2013 and higher.  Since this is strictly a utility, and since we hope
to drop support for MSVC 2012 soon, don't build this unless MSVC 2013 or
higher.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227479 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 18:44:14 +00:00
Michael J. Spencer
ab9c16107e [lto] Disable dialog boxes on crash on Windows.
This has to be done in the DLL because the state doesn't cross DLL boundaries.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227471 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 17:20:41 +00:00
Aaron Ballman
71f6e95824 Oops -- accidentally commit some debug code! Removing that code; NFC (this time for real).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227459 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 16:18:59 +00:00
Aaron Ballman
9ee155b800 Attempting to fix a build issue with MSVC 2012; NFC
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227456 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 16:02:06 +00:00
Reid Kleckner
f77571aeac Add a Windows EH preparation pass that zaps resumes
If the personality is not a recognized MSVC personality function, this
pass delegates to the dwarf EH preparation pass. This chaining supports
people on *-windows-itanium or *-windows-gnu targets.

Currently this recognizes some personalities used by MSVC and turns
resume instructions into traps to avoid link errors.  Even if cleanups
are not used in the source program, LLVM requires the frontend to emit a
code path that resumes unwinding after an exception.  Clang does this,
and we get unreachable resume instructions. PR20300 covers cleaning up
these unreachable calls to resume.

Reviewers: majnemer

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227405 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 00:41:44 +00:00
Frederic Riss
3ddec31300 [dsymutil] Gather the DIE tree child->parent relationships.
The libDebugInfo DIE parsing doesn't store these relationships, we have to
recompute them. This commit introduces the CompileUnit bookkeeping class to
store this data. It will be expanded with more fields in the future.

No tests as this produces no visible output.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227382 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 22:15:14 +00:00
Bjorn Steinbrink
dd4a5df6e1 Fix build breakage caused by memory leaks in llvm-c-test
I accidently introduced those in r227319.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227339 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 18:32:31 +00:00
Frederic Riss
b616a18f02 [dsymutil] Add DwarfLinker class.
It's an empty shell for now. It's main method just opens the debug
map objects and parses their Dwarf info. Test that we at least do
that correctly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227337 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 18:27:01 +00:00
Bjorn Steinbrink
920382c5aa Fix LLVMSetMetadata and LLVMAddNamedMetadataOperand for single value MDNodes
Summary:
MetadataAsValue uses a canonical format that strips the MDNode if it
contains only a single constant value. This triggers an assertion when
trying to cast the value to a MDNode.

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227319 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 16:35:59 +00:00
David Majnemer
e02ee8cf05 llvm-ar: Remove unimplemented -N option from -help
This fixes PR22358.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227296 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 06:00:01 +00:00
Zachary Turner
e0f25c2962 [llvm-pdbdump] Add basic symbol dumping.
This adds two command line options:

--symbols dumps a list of all symbols found in the PDB.
--symbol-details dumps the same list, but with detailed information
                 for every symbol such as type, attributes, etc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227286 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 01:22:33 +00:00
Zachary Turner
e32b7636e7 [llvm-pdbdump] Add support for printing source files and compilands.
This adds two command line options to llvm-pdbdump.

--source-files prints a flat list of all source files in the PDB.

--compilands prints a list of all compilands (e.g. object files)
             that the PDB knows about, and for each one, a list of
             source files that the compiland is composed of as well
             as a hash of the original source file.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227276 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 00:33:00 +00:00
Zachary Turner
63f47de72c [llvm-pdbdump] Print more friendly names for enum values.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227275 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 00:32:49 +00:00
Zachary Turner
7ce32460db Run dos2unix against llvm-pdbdump.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227262 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-27 23:02:23 +00:00
Zachary Turner
0f9950ed0c Add support for dumping debug tables to llvm-pdbdump.
PDB stores some of its data in streams and some in tables.
This patch teaches llvm-pdbdump to dump basic summary data
for the debug tables.

In support of this, this patch also adds some DIA helper
classes, such as a wrapper around an IDiaSymbol interface,
as well as helpers for outputting various enumerations to
a raw_ostream.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227257 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-27 22:40:14 +00:00
Kevin Enderby
a167fe1877 dd the option, -link-opt-hints to llvm-objdump used with -macho to print the
Mach-O AArch64 linker optimization hints for ADRP code optimization.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227246 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-27 21:28:24 +00:00
Zachary Turner
c1592bca1e Add llvm-pdbdump to tools.
llvm-pdbdump is a tool which can be used to dump the contents
of Microsoft-generated PDB files.  It makes use of the Microsoft
DIA SDK, which is a COM based library designed specifically for
this purpose.

The initial commit of this tool dumps the raw bytes from PDB data
streams.  Future commits will dump more semantic information such
as types, symbols, source files, etc similar to the types of
information accessible via llvm-dwarfdump.

Reviewed by: Aaron Ballman, Reid Kleckner, Chandler Carruth
Differential Revision: http://reviews.llvm.org/D7153

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227241 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-27 20:46:21 +00:00
Eric Christopher
04bcc11905 Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.

*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227113 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-26 19:03:15 +00:00
Simon Atanasyan
09a46075ee [ELFYAML] Support mips64 relocation record format in yaml2obj/obj2yaml
MIPS64 ELF file has a very specific relocation record format. Each
record might specify up to three relocation operations. So the `r_info`
field in fact consists of three relocation type sub-fields and optional
code of "special" symbols.

http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
page 40

The patch implements support of the MIPS64 relocation record format in
yaml2obj/obj2yaml tools by introducing new optional Relocation fields:
Type2, Type3, and SpecSym. These fields are recognized only if the
object/YAML file relates to the MIPS64 target.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227044 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-25 13:29:25 +00:00
Sylvestre Ledru
f85bc8ac5a Update of the gold-plugin.cpp code to match Chandler's changes (r226981)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227004 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-24 13:59:08 +00:00
Chandler Carruth
d4f6d111c1 [PM] Port LowerExpectIntrinsic to the new pass manager.
This just lifts the logic into a static helper function, sinks the
legacy pass to be a trivial wrapper of that helper fuction, and adds
a trivial wrapper for the new PM as well. Not much to see here.

I switched a test case to run in both modes, but we have to strip the
dead prototypes separately as that pass isn't in the new pass manager
(yet).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226999 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-24 11:13:02 +00:00
Chandler Carruth
7a98df7f74 [PM] Port instcombine to the new pass manager!
This is exciting as this is a much more involved port. This is
a complex, existing transformation pass. All of the core logic is shared
between both old and new pass managers. Only the access to the analyses
is separate because the actual techniques are separate. This also uses
a bunch of different and interesting analyses and is the first time
where we need to use an analysis across an IR layer.

This also paves the way to expose instcombine utility functions. I've
got a static function that implements the core pass logic over
a function which might be mildly interesting, but more interesting is
likely exposing a routine which just uses instructions *already in* the
worklist and combines until empty.

I've switched one of my favorite instcombine tests to run with both as
well to make sure this keeps working.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226987 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-24 04:19:17 +00:00
Chandler Carruth
6f409cbc05 [PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]

When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:

While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.

A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.

This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.

It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.

The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.

One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.

The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226981 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-24 02:06:09 +00:00
Lang Hames
4f437717d4 [Orc] Add orcjit to the dependencies list in the Makefile for lli.
This should fix a few more broken bots.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226973 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-24 00:01:29 +00:00
Justin Bogner
c6945d9e32 llvm-cov: Don't use llvm::outs() in library code
Nothing in lib/ should be using llvm::outs() directly. Thread it in
from the caller instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226961 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 23:09:27 +00:00
Lang Hames
63cc4f56a9 [Orc] New JIT APIs.
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226940 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:25:00 +00:00
Kevin Enderby
f9857eb016 Fix the problem with llvm-objdump and -archive-headers in printing the archive header size field.
This problem showed up with the clang-cmake-armv7-a15-full bot.  Thanks to Renato Golin for his help.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226936 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 21:02:44 +00:00
Colin LeMahieu
88fa664c1b [Objdump] Output information about common symbols in a way closer to GNU objdump.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226932 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 20:06:24 +00:00
Kevin Enderby
66e2ddc870 Add the option, -data-in-code, to llvm-objdump used with -macho to print the Mach-O data in code table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226921 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 18:52:17 +00:00
Rafael Espindola
eb3eb88fb7 Add STB_GNU_UNIQUE to the ELF writer.
This lets llvm-mc assemble files produced by gcc.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226895 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-23 04:44:35 +00:00
Chandler Carruth
9a78a64776 [PM] Actually add the new pass manager support for the assumption cache.
I had already factored this analysis specifically to enable doing this,
but hadn't actually committed the necessary wiring to get at this from
the new pass manager. This also nicely shows how the separate cache
object can be directly managed by the new pass manager.

This analysis didn't have any direct tests and so I've added a printer
pass and a boring test case. I chose to print the i1 value which is
being assumed rather than the call to llvm.assume as that seems much
more useful for testing... but suggestions on an even better printing
strategy welcome. My main goal was to make sure things actually work. =]

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226868 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-22 21:53:09 +00:00
Kevin Enderby
bcbb8690cb Add the option, -indirect-symbols, used with -macho to print the Mach-O indirect symbol table to llvm-objdump.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226848 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-22 18:55:27 +00:00
Chris Bieneman
e84c7b1116 Assigning and copying command line option objects shouldn't be allowed.
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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226762 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-22 01:49:59 +00:00
Kevin Enderby
c97fb73e2f For llvm-objdump, hook up existing options to work when using -macho (the Mach-O parser).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226612 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 21:47:46 +00:00
Chandler Carruth
a37512049c [PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysis
pass and a LoopPrinterPass with the expected associated wiring.

I've added a RUN line to the only test case (!!!) we have that actually
prints loops. Everything seems to be working.

This is somewhat exciting as this is the first analysis using another
analysis to go in for the new pass manager. =D I also believe it is the
last analysis necessary for porting instcombine, but of course I may yet
discover more.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226560 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 10:58:50 +00:00
Frederic Riss
8732027cd8 [dsymutil] Add the detected target triple to the debug map.
It will be needed to instantiate the Target object that we will
use to create all the MC objects for the dwarf emission.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226525 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-19 23:33:14 +00:00
David Blaikie
5f16ba708b unique_ptrify the RelInfo parameter to TargetRegistry::createMCSymbolizer
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226416 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-18 20:45:48 +00:00