1
0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-14 11:32:34 +00:00
Commit Graph

103 Commits

Author SHA1 Message Date
Rafael Espindola
9758b4ae95 Simplify the Mangler interface now that DataLayout is mandatory.
We only need to pass in a DataLayout when mangling a raw string, not when
constructing the mangler.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240405 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-23 13:59:29 +00:00
Peter Collingbourne
3fcf5a99cb Make the C++ LTO API easier to use from C++ clients.
Start using C++ types such as StringRef and MemoryBuffer in the C++ LTO
API. In doing so, clarify the ownership of the native object file: the caller
now owns it, not the LTOCodeGenerator. The C libLTO library has been modified
to use a derived class of LTOCodeGenerator that owns the object file.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238776 91177308-0d34-0410-b5e6-96231b3b80d8
2015-06-01 20:08:30 +00:00
Duncan P. N. Exon Smith
0b29dea9f1 LTO: Add API to choose whether to embed uselists
Reverse libLTO's default behaviour for preserving use-list order in
bitcode, and add API for controlling it.  The default setting is now
`false` (don't preserve them), which is consistent with `clang`'s
default behaviour.

Users of libLTO should call `lto_codegen_should_embed_uselists(CG,true)`
prior to calling `lto_codegen_write_merged_modules()` whenever the
output file isn't part of the production workflow in order to reproduce
results with subsequent calls to `llc`.

(I haven't added tests since `llvm-lto` (the test tool for LTO) doesn't
support bitcode output, and even if it did: there isn't actually a good
way to test whether a tool has passed the flag.  If the order is already
"natural" (if the order will already round-trip) then no use-list
directives are emitted at all.  At some point I'll circle back to add
tests to `llvm-as` (etc.) that they actually respect the flag, at which
point I can somehow add a test here as well.)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235943 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-27 23:38:54 +00:00
Duncan P. N. Exon Smith
ae51ba7ea1 LTO: Simplify code generator initialization
Simplify `LTOCodeGenerator` initialization by initializing simple fields
at their definition.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235939 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-27 23:19:26 +00:00
Manman Ren
44b800f44d [LTO API] add lto_codegen_set_should_internalize.
When debugging LTO issues with ld64, we use -save-temps to save the merged
optimized bitcode file, then invoke ld64 again on the single bitcode file.
The saved bitcode file is already internalized, so we can call
lto_codegen_set_should_internalize and skip running internalization again.

rdar://20227235


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@235211 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-17 17:10:09 +00:00
Duncan P. N. Exon Smith
8d61ee9e7d uselistorder: Remove the global bits
Remove all the global bits to do with preserving use-list order by
moving the `cl::opt`s to the individual tools that want them.  There's a
minor functionality change to `libLTO`, in that you can't send in
`-preserve-bc-uselistorder=false`, but making that bit settable (if it's
worth doing) should be through explicit LTO API.

As a drive-by fix, I removed some includes of `UseListOrder.h` that were
made unnecessary by recent commits.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234973 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 03:14:06 +00:00
Duncan P. N. Exon Smith
657aad675a uselistorder: Pull the bit through WriteToBitcodFile()
Change the callers of `WriteToBitcodeFile()` to pass `true` or
`shouldPreserveBitcodeUseListOrder()` explicitly.  I left the callers
that want to send `false` alone.

I'll keep pushing the bit higher until hopefully I can delete the global
`cl::opt` entirely.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234957 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-15 00:10:50 +00:00
Rafael Espindola
c98092e28d Use raw_pwrite_stream in the object writer/streamer.
The ELF object writer will take advantage of that in the next commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234950 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 22:14:34 +00:00
Duncan P. N. Exon Smith
d044549557 IR: Set -preserve-bc-uselistorder=false by default
But keep it on by default in `llvm-as`, `opt`, `bugpoint`, `llvm-link`,
`llvm-extract`, and `LTOCodeGenerator`.  Part of PR5680.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234921 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 18:33:00 +00:00
Rafael Espindola
427c073035 Simplify use of formatted_raw_ostream.
formatted_raw_ostream is a wrapper over another stream to add column and line
number tracking.

It is used only for asm printing.

This patch moves the its creation down to where we know we are printing
assembly. This has the following advantages:

* Simpler lifetime management: std::unique_ptr
* We don't compute column and line number of object files :-)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234535 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-09 21:06:08 +00:00
Rafael Espindola
a93117c50d This reverts commit r234460 and r234461.
Revert "Add classof implementations to the raw_ostream classes."
Revert "Use the cast machinery to remove dummy uses of formatted_raw_ostream."

The underlying issue can be fixed without classof.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234495 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-09 15:54:59 +00:00
Rafael Espindola
23295f613b Use the cast machinery to remove dummy uses of formatted_raw_ostream.
If we know we are producing an object, we don't need to wrap the stream
in a formatted_raw_ostream anymore.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234461 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-09 02:28:12 +00:00
Manman Ren
df9febccc7 [LTO] do not run internalize pass from compileOptimized.
The input to compileOptimized is already optimized and internalized, so remove
internalize pass from compileOptimized.

rdar://20227235


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234446 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-08 22:02:11 +00:00
Duncan P. N. Exon Smith
a60d430e31 Verifier: Remove the separate -verify-di pass
Remove `DebugInfoVerifierLegacyPass` and the `-verify-di` pass.
Instead, call into the `DebugInfoVerifier` from inside
`VerifierLegacyPass::finalizeModule()`.  This better matches the logic
in `verifyModule()` (used by the new PassManager), avoids requiring two
separate passes to verify the IR, and makes the API for "add a pass to
verify the IR" simple.

Note: the `-verify-debug-info` flag still works (for now, at least;
eventually it might make sense to just remove it).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232772 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-19 22:24:17 +00:00
Peter Collingbourne
416d8ecf80 libLTO, llvm-lto, gold: Introduce flag for controlling optimization level.
This change also introduces a link-time optimization level of 1. This
optimization level runs only the globaldce pass as well as cleanup passes for
passes that run at -O0, specifically simplifycfg which cleans up lowerbitsets.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150316/266951.html

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232769 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-19 22:01:00 +00:00
Mehdi Amini
c94da20917 Make DataLayout Non-Optional in the Module
Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

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

From: Mehdi Amini <mehdi.amini@apple.com>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231270 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-04 18:43:29 +00:00
Manman Ren
f2a351a514 [LTO API] fix memory leakage introduced at r230290.
r230290 released the LLVM module but not the LTOModule.

rdar://19024554


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230544 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25 21:20:53 +00:00
Manman Ren
bd26e6a006 [LTO API] add lto_codegen_set_module to set the destination module.
When debugging LTO issues with ld64, we use -save-temps to save the merged
optimized bitcode file, then invoke ld64 again on the single bitcode file to
speed up debugging code generation passes and ld64 stuff after code generation.

llvm linking a single bitcode file via lto_codegen_add_module will generate a
different bitcode file from the single input. With the newly-added
lto_codegen_set_module, we can make sure the destination module is the same as
the input.

lto_codegen_set_module will transfer the ownship of the module to code
generator.

rdar://19024554


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230290 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-24 00:45:56 +00:00
Chandler Carruth
417c5c172c [PM] Remove the old 'PassManager.h' header file at the top level of
LLVM's include tree and the use of using declarations to hide the
'legacy' namespace for the old pass manager.

This undoes the primary modules-hostile change I made to keep
out-of-tree targets building. I sent an email inquiring about whether
this would be reasonable to do at this phase and people seemed fine with
it, so making it a reality. This should allow us to start bootstrapping
with modules to a certain extent along with making it easier to mix and
match headers in general.

The updates to any code for users of LLVM are very mechanical. Switch
from including "llvm/PassManager.h" to "llvm/IR/LegacyPassManager.h".
Qualify the types which now produce compile errors with "legacy::". The
most common ones are "PassManager", "PassManagerBase", and
"FunctionPassManager".

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229094 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-13 10:01:29 +00:00
Manman Ren
69e4dd1b12 [LTO API] split lto_codegen_compile to lto_codegen_optimize and
lto_codegen_compile_optimized. Also add lto_api_version.

Before this commit, we can only dump the optimized bitcode after running
lto_codegen_compile, but it includes some impacts of running codegen passes,
one example is StackProtector pass. We will get assertion failure when running
llc on the optimized bitcode, because StackProtector is effectively run twice.

After splitting lto_codegen_compile, the linker can choose to dump the bitcode
before running lto_codegen_compile_optimized.

lto_api_version is added so ld64 can check for runtime-availability of the new
API.

rdar://19565500


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228000 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 18:39:15 +00:00
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
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
b4a44570f6 [PM] Sink the population of the pass manager with target-specific
analyses back into the LTO code generator.

The pass manager builder (and the transforms library in general)
shouldn't be referencing the target machine at all.

This makes the LTO population work like the others -- the data layout
and target transform info need to be pre-populated.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227576 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 13:33:42 +00:00
Akira Hatanaka
6953381b0c [LTO] Scan all per-function subtargets when collecting runtime library names.
accumulateAndSortLibcalls in LTOCodeGenerator.cpp collects names of runtime
library functions which are used to identify user-defined functions that should
be protected. Previously, this function would only scan the TargetLowering
object belonging to the "main" subtarget for the library function names. This
commit changes it to scan all per-function subtargets.

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


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227533 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-30 01:16:24 +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
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
Chandler Carruth
622a4bdaa7 [PM] Separate the InstCombiner from its pass.
This creates a small internal pass which runs the InstCombiner over
a function. This is the hard part of porting InstCombine to the new pass
manager, as at this point none of the code in InstCombine has access to
a Pass object any longer.

The resulting interface for the InstCombiner is pretty terrible. I'm not
planning on leaving it that way. The key thing missing is that we need
to separate the worklist from the combiner a touch more. Once that's
done, it should be possible for *any* part of LLVM to just create
a worklist with instructions, populate it, and then combine it until
empty. The pass will just be the (obvious and important) special case of
doing that for an entire function body.

For now, this is the first increment of factoring to make all of this
work.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226618 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 22:44:35 +00:00
Chandler Carruth
bda134910a [PM] Move TargetLibraryInfo into the Analysis library.
While the term "Target" is in the name, it doesn't really have to do
with the LLVM Target library -- this isn't an abstraction which LLVM
targets generally need to implement or extend. It has much more to do
with modeling the various runtime libraries on different OSes and with
different runtime environments. The "target" in this sense is the more
general sense of a target of cross compilation.

This is in preparation for porting this analysis to the new pass
manager.

No functionality changed, and updates inbound for Clang and Polly.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226078 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-15 02:16:27 +00:00
Duncan P. N. Exon Smith
ab75fd0694 libLTO: Assert if LTOCodeGenerator and LTOModule are from different contexts
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221730 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 23:13:10 +00:00
Duncan P. N. Exon Smith
bce40075a9 libLTO: Allow LTOCodeGenerator to own a context
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221726 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 23:03:29 +00:00
Arnold Schwaighofer
b26fb77d9b Add an option to the LTO code generator to disable vectorization during LTO
We used to always vectorize (slp and loop vectorize) in the LTO pass pipeline.

r220345 changed it so that we used the PassManager's fields 'LoopVectorize' and
'SLPVectorize' out of the desire to be able to disable vectorization using the
cl::opt flags 'vectorize-loops'/'slp-vectorize' which the before mentioned
fields default to.
Unfortunately, this turns off vectorization because those fields
default to false.
This commit adds flags to the LTO library to disable lto vectorization which
reconciles the desire to optionally disable vectorization during LTO and
the desired behavior of defaulting to enabled vectorization.

We really want tools to set PassManager flags directly to enable/disable
vectorization and not go the route via cl::opt flags *in*
PassManagerBuilder.cpp.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220652 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-26 21:50:58 +00:00
Rafael Espindola
72478e59c7 Update the error handling of lib/Linker.
Instead of passing a std::string&, use the new diagnostic infrastructure.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220608 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-25 04:06:10 +00:00
Duncan P. N. Exon Smith
49048ecf56 LTO: Document the Boolean argument from r218784
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218907 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-02 21:11:04 +00:00
Duncan P. N. Exon Smith
04d2186546 LTO: Ignore disabled diagnostic remarks
r206400 and r209442 added remarks that are disabled by default.
However, if a diagnostic handler is registered, the remarks are sent
unfiltered to the handler.  This is the right behaviour for clang, since
it has its own filters.

However, the diagnostic handler exposed in the LTO API receives only the
severity and message.  It doesn't have the information to filter by pass
name.  For LTO, disabled remarks should be filtered by the producer.

I've changed `LLVMContext::setDiagnosticHandler()` to take a `bool`
argument indicating whether to respect the built-in filters.  This
defaults to `false`, so other consumers don't have a behaviour change,
but `LTOCodeGenerator::setDiagnosticHandler()` sets it to `true`.

To make this behaviour testable, I added a `-use-diagnostic-handler`
command-line option to `llvm-lto`.

This fixes PR21108.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@218784 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-01 18:36:03 +00:00
Rafael Espindola
3b670550ad Add doInitialization/doFinalization to DataLayoutPass.
With this a DataLayoutPass can be reused for multiple modules.

Once we have doInitialization/doFinalization, it doesn't seem necessary to pass
a Module to the constructor.

Overall this change seems in line with the idea of making DataLayout a required
part of Module. With it the only way of having a DataLayout used is to add it
to the Module.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217548 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-10 21:27:43 +00:00
David Blaikie
fc5b232004 unique_ptrify LTOCodeGenerator::NativeObjectFile
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216927 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-02 18:21:06 +00:00
Craig Topper
16edb0e930 Fix some cases were ArrayRefs were being passed by reference. Also remove 'const' from some other ArrayRef uses since its implicitly const already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216524 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-27 05:25:00 +00:00
Rafael Espindola
8c96862847 Modernize raw_fd_ostream's constructor a bit.
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.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216393 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-25 18:16:47 +00:00
Rafael Espindola
7b4eb02b6d Move some logic to populateLTOPassManager.
This will avoid code duplication in the next commit which calls it directly
from the gold plugin.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216211 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 20:03:44 +00:00
Rafael Espindola
4658ea9dc7 Respect LibraryInfo in populateLTOPassManager and use it. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216203 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 18:49:52 +00:00
Rafael Espindola
0b994a70b0 Handle inlining in populateLTOPassManager like in populateModulePassManager.
No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216178 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 13:35:30 +00:00
Rafael Espindola
47199c3d0c Move DisableGVNLoadPRE from populateLTOPassManager to PassManagerBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216174 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 13:13:17 +00:00
Craig Topper
431bdfc4c1 Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216158 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 05:55:13 +00:00
Craig Topper
db77b82ed5 Revert "Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size."
Getting a weird buildbot failure that I need to investigate.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215870 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 00:24:38 +00:00
Craig Topper
f06c7072c2 Repace SmallPtrSet with SmallPtrSetImpl in function arguments to avoid needing to mention the size.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215868 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-17 23:47:00 +00:00
Rafael Espindola
0ca286752e Don't internalize all but main by default.
This is mostly a cleanup, but it changes a fairly old behavior.

Every "real" LTO user was already disabling the silly internalize pass
and creating the internalize pass itself. The difference with this
patch is for "opt -std-link-opts" and the C api.

Now to get a usable behavior out of opt one doesn't need the funny
looking command line:

opt -internalize -disable-internalize -internalize-public-api-list=foo,bar -std-link-opts

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214919 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 20:10:38 +00:00
Eric Christopher
9f85dccfc6 Remove the TargetMachine forwards for TargetSubtargetInfo based
information and update all callers. No functional change.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214781 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-04 21:25:23 +00:00
Tim Northover
9231148e69 AArch64: remove arm64 triple enumerator.
Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and
invites bugs where only one is checked. In reality, the only legitimate
difference between the two (arm64 usually means iOS) is also present in the OS
part of the triple and that's what should be checked.

We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so
there aren't any LLVM-side test changes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213743 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 12:32:47 +00:00
Gerolf Hoflehner
d94715e273 MergedLoadStoreMotion pass
Merges equivalent loads on both sides of a hammock/diamond
and hoists into into the header.
Merges equivalent stores on both sides of a hammock/diamond
and sinks it to the footer.
Can enable if conversion and tolerate better load misses
and store operand latencies.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213396 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 19:13:09 +00:00
Rafael Espindola
7cba2a973f Update the MemoryBuffer API to use ErrorOr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212405 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-06 17:43:13 +00:00