gold to work. Since the enum value LDPO_PIE has just been added to plugin-api.h,
use a numeric constant for now so that we don't require an unreleased
version of gold to build.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158402 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM is now -Wunused-private-field clean except for
- lib/MC/MCDisassembler/Disassembler.h. Not sure why it keeps all those unaccessible fields.
- gtest.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158096 91177308-0d34-0410-b5e6-96231b3b80d8
There are some that I didn't remove this round because they looked like
obvious stubs. There are dead variables in gtest too, they should be
fixed upstream.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158090 91177308-0d34-0410-b5e6-96231b3b80d8
This broke in r144788 when the CodeGenOpt option was moved from everywhere else
(specifically, from addPassesToEmitFile) to createTargetMachine. Since
LTOCodeGenerator wasn't passing the 4th argument, when the 4th parameter became
the 3rd, it silently continued to compile (int->bool conversion) but meant
something completely different.
This change preserves the existing (accidental) and previous (default)
semantics of the addPassesToEmitFile and restores the previous/intended
CodeGenOpt argument by passing it appropriately to createTargetMachine.
(discovered by pending changes to -Wconversion to catch constant->bool
conversions)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157705 91177308-0d34-0410-b5e6-96231b3b80d8
Besides adding the new insertPass function, this patch uses it to
enhance the existing -print-machineinstrs so that the MachineInstrs
after a specific pass can be printed.
Patch by Bin Zeng!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157655 91177308-0d34-0410-b5e6-96231b3b80d8
Use a dedicated MachO load command to annotate data-in-code regions.
This is the same format the linker produces for final executable images,
allowing consistency of representation and use of introspection tools
for both object and executable files.
Data-in-code regions are annotated via ".data_region"/".end_data_region"
directive pairs, with an optional region type.
data_region_directive := ".data_region" { region_type }
region_type := "jt8" | "jt16" | "jt32" | "jta32"
end_data_region_directive := ".end_data_region"
The previous handling of ARM-style "$d.*" labels was broken and has
been removed. Specifically, it didn't handle ARM vs. Thumb mode when
marking the end of the section.
rdar://11459456
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157062 91177308-0d34-0410-b5e6-96231b3b80d8
It's more flexible for MCJIT tasks, in addition it's provides a invalidation instruction cache for code sections which will be used before JIT code will be executed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156933 91177308-0d34-0410-b5e6-96231b3b80d8
options, to enable easier testing of the innards of LLVM that are
enabled by such optimization strategies.
Note that this doesn't provide the (much needed) function attribute
support for -Oz (as opposed to -Os), but still seems like a positive
step to better test the logic that Clang currently relies on.
Patch by Patrik Hägglund.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156913 91177308-0d34-0410-b5e6-96231b3b80d8
Add the MCRegisterInfo to the factories and constructors.
Patch by Tom Stellard <Tom.Stellard@amd.com>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156828 91177308-0d34-0410-b5e6-96231b3b80d8
My previous change to install llvm-config-host for cross-builds resulted
in that file being installed even when the normal llvm-config was not
installed, e.g., when building the install-clang target. Daniel suggested
this alternative, which solves the immediate problem and also avoids the gunk
in the top-level makefile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156448 91177308-0d34-0410-b5e6-96231b3b80d8
and expose it as a utility class rather than as free function wrappers.
The simple free-function interface works well for the bugpoint-specific
pass's uses of code extraction, but in an upcoming patch for more
advanced code extraction, they simply don't expose a rich enough
interface. I need to expose various stages of the process of doing the
code extraction and query information to decide whether or not to
actually complete the extraction or give up.
Rather than build up a new predicate model and pass that into these
functions, just take the class that was actually implementing the
functions and lift it up into a proper interface that can be used to
perform code extraction. The interface is cleaned up and re-documented
to work better in a header. It also is now setup to accept the blocks to
be extracted in the constructor rather than in a method.
In passing this essentially reverts my previous commit here exposing
a block-level query for eligibility of extraction. That is no longer
necessary with the more rich interface as clients can query the
extraction object for eligibility directly. This will reduce the number
of walks of the input basic block sequence by quite a bit which is
useful if this enters the normal optimization pipeline.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156163 91177308-0d34-0410-b5e6-96231b3b80d8
While making lld build under the tools directory I decided to refactor how this
works.
There is now a macro, add_llvm_external_project, which takes the name of the
expected subdirectory. This sets up two CMake options.
* LLVM_EXTERNAL_${NAME}_SOURCE_DIR
This is the path to the source. It defaults to
${CMAKE_CURRENT_SOURCE_DIR}/${name}.
* LLVM_EXTERNAL_${NAME}_BUILD
Enable and disable building the tool as part of LLVM.
I chose LLVM_EXTERNAL_${NAME} as a prefix so they all show up together in the
GUI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155654 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155147 91177308-0d34-0410-b5e6-96231b3b80d8
The test change is to account for the fact that the default disassembler behaviour has changed with regards to specifying the assembly syntax to use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154809 91177308-0d34-0410-b5e6-96231b3b80d8
so we don't want it to show up in the stable 3.1 interface.
While at it, add a comment about why LTOCodeGenerator manually creates the
internalize pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154807 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantFP::get(Type*, double) is unreliably host-specific:
it can't handle a type like PPC128 on an x86 host. It even
has a comment to that effect: "This should only be used for
simple constant values like 2.0/1.0 etc, that are
known-valid both as host double and as the target format."
Instead, use APFloat. While we're at it, randomize the floating
point value more thoroughly; it was previously limited
to the range 0 to 2**19 - 1.
PR12451.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154446 91177308-0d34-0410-b5e6-96231b3b80d8
LangRef.html says:
"There are no arrays, vectors or constants of this type."
This was hitting assertions when passing the -generate-x86-mmx
option.
PR12452.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154445 91177308-0d34-0410-b5e6-96231b3b80d8
optimizations which are valid for position independent code being linked
into a single executable, but not for such code being linked into
a shared library.
I discussed the design of this with Eric Christopher, and the decision
was to support an optional bit rather than a completely separate
relocation model. Fundamentally, this is still PIC relocation, its just
that certain optimizations are only valid under a PIC relocation model
when the resulting code won't be in a shared library. The simplest path
to here is to expose a single bit option in the TargetOptions. If folks
have different/better designs, I'm all ears. =]
I've included the first optimization based upon this: changing TLS
models to the *Exec models when PIE is enabled. This is the LLVM
component of PR12380 and is all of the hard work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154294 91177308-0d34-0410-b5e6-96231b3b80d8
Consider the following program:
$ cat main.c
void foo(void) { }
int main(int argc, char *argv[]) {
foo();
return 0;
}
$ cat bundle.c
extern void foo(void);
void bar(void) {
foo();
}
$ clang -o main main.c
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
$ nm -m bundle.so
0000000000000f40 (__TEXT,__text) external _bar
(undefined) external _foo (from executable)
(undefined) external dyld_stub_binder (from libSystem)
$ clang -o main main.c -O4
$ clang -o bundle.so bundle.c -bundle -bundle_loader ./main
Undefined symbols for architecture x86_64:
"_foo", referenced from:
_bar in bundle-elQN6d.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
The linker was told that the 'foo' in 'main' was 'internal' and had no uses, so
it was dead stripped.
Another situation is something like:
define void @foo() {
ret void
}
define void @bar() {
call asm volatile "call _foo" ...
ret void
}
The only use of 'foo' is inside of an inline ASM call. Since we don't look
inside those for uses of functions, we don't specify this as a "use."
Get around this by not invoking the 'internalize' pass by default. This is an
admitted hack for LTO correctness.
<rdar://problem/11185386>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154124 91177308-0d34-0410-b5e6-96231b3b80d8
reflected in the LLVM IR (as a declare or something), then treat it like a data
object.
N.B. This isn't 100% correct. The ASM parser should supply more information so
that we know what type of object it is, and what attributes it should have.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153870 91177308-0d34-0410-b5e6-96231b3b80d8
definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153859 91177308-0d34-0410-b5e6-96231b3b80d8
1. The main works will made in the RuntimeDyLdImpl with uses the ObjectFile class. RuntimeDyLdMachO and RuntimeDyLdELF now only parses relocations and resolve it. This is allows to make improvements of the RuntimeDyLd more easily. In addition the support for COFF can be easily added.
2. Added ARM relocations to RuntimeDyLdELF.
3. Added support for stub functions for the ARM, allowing to do a long branch.
4. Added support for external functions that are not loaded from the object files, but can be loaded from external libraries. Now MCJIT can correctly execute the code containing the printf, putc, and etc.
5. The sections emitted instead functions, thanks Jim Grosbach. MemoryManager.startFunctionBody() and MemoryManager.endFunctionBody() have been removed.
6. MCJITMemoryManager.allocateDataSection() and MCJITMemoryManager. allocateCodeSection() used JMM->allocateSpace() instead of JMM->allocateCodeSection() and JMM->allocateDataSection(), because I got an error: "Cannot allocate an allocated block!" with object file contains more than one code or data sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153754 91177308-0d34-0410-b5e6-96231b3b80d8
Module-level ASM may contain definitions of functions and globals. However, we
were not telling the linker that these globals had definitions. As far as it was
concerned, they were just declarations.
Attempt to resolve this by inserting module-level ASM functions and globals into
the '_symbol' set so that the linker will know that they have values.
This gets us further towards our goal of compiling LLVM, but it still has
problems when linking libLTO.dylib because of the `-dead_strip' flag that's
passed to the linker.
<rdar://problem/11124216>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153638 91177308-0d34-0410-b5e6-96231b3b80d8
(and hopefully on Windows). The bots have been down most of the day
because of this, and it's not clear to me what all will be required to
fix it.
The commits started with r153205, then r153207, r153208, and r153221.
The first commit seems to be the real culprit, but I couldn't revert
a smaller number of patches.
When resubmitting, r153207 and r153208 should be folded into r153205,
they were simple build fixes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153241 91177308-0d34-0410-b5e6-96231b3b80d8
1) opt is not usually in the same path as the target program. Even for
the bugpoint as a standalone app, it should be more portable to search
in PATH, isn't it?
2) bugpoint driver accounts opt plugins, but does not list them in the
final output command.
Patch by Dmitry Mikushin!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@153066 91177308-0d34-0410-b5e6-96231b3b80d8
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.
This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152620 91177308-0d34-0410-b5e6-96231b3b80d8
Renamed methods caseBegin, caseEnd and caseDefault with case_begin, case_end, and case_default.
Added some notes relative to case iterators.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152532 91177308-0d34-0410-b5e6-96231b3b80d8
* Add enums and structures for GNU version information.
* Implement extraction of that information on a per-symbol basis (ELFObjectFile::getSymbolVersion).
* Implement a generic interface, GetELFSymbolVersion(), for getting the symbol version from the ObjectFile (hides the templating).
* Have llvm-readobj print out the version, when available.
* Add a test for the new feature: readobj-elf-versioning.test
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152436 91177308-0d34-0410-b5e6-96231b3b80d8
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120130/136146.html
Implemented CaseIterator and it solves almost all described issues: we don't need to mix operand/case/successor indexing anymore. Base iterator class is implemented as a template since it may be initialized either from "const SwitchInst*" or from "SwitchInst*".
ConstCaseIt is just a read-only iterator.
CaseIt is read-write iterator; it allows to change case successor and case value.
Usage of iterator allows totally remove resolveXXXX methods. All indexing convertions done automatically inside the iterator's getters.
Main way of iterator usage looks like this:
SwitchInst *SI = ... // intialize it somehow
for (SwitchInst::CaseIt i = SI->caseBegin(), e = SI->caseEnd(); i != e; ++i) {
BasicBlock *BB = i.getCaseSuccessor();
ConstantInt *V = i.getCaseValue();
// Do something.
}
If you want to convert case number to TerminatorInst successor index, just use getSuccessorIndex iterator's method.
If you want initialize iterator from TerminatorInst successor index, use CaseIt::fromSuccessorIndex(...) method.
There are also related changes in llvm-clients: klee and clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@152297 91177308-0d34-0410-b5e6-96231b3b80d8
* Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile.
* Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable.
* Implement this new interface completely for ELF, leave stubs for COFF and MachO.
* Add 'llvm-readobj' tool for dumping ObjectFile information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151785 91177308-0d34-0410-b5e6-96231b3b80d8
Rename ST_External to ST_Unknown, and slightly change its semantics. It now only indicates that the symbol's type
is unknown, not that the symbol is undefined. (For that, use ST_Undefined).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151696 91177308-0d34-0410-b5e6-96231b3b80d8
Creates a configurable regalloc pipeline.
Ensure specific llc options do what they say and nothing more: -reglloc=... has no effect other than selecting the allocator pass itself. This patch introduces a new umbrella flag, "-optimize-regalloc", to enable/disable the optimizing regalloc "superpass". This allows for example testing coalscing and scheduling under -O0 or vice-versa.
When a CodeGen pass requires the MachineFunction to have a particular property, we need to explicitly define that property so it can be directly queried rather than naming a specific Pass. For example, to check for SSA, use MRI->isSSA, not addRequired<PHIElimination>.
CodeGen transformation passes are never "required" as an analysis
ProcessImplicitDefs does not require LiveVariables.
We have a plan to massively simplify some of the early passes within the regalloc superpass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150226 91177308-0d34-0410-b5e6-96231b3b80d8
This CL delays reading of function bodies from initial parse until
materialization, allowing overlap of compilation with bitcode download.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149918 91177308-0d34-0410-b5e6-96231b3b80d8
but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul. Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149800 91177308-0d34-0410-b5e6-96231b3b80d8
dylib. This regressed with r145408. I will try to make a test case and add it
so that this doesn't happen again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149667 91177308-0d34-0410-b5e6-96231b3b80d8
The purpose of refactoring is to hide operand roles from SwitchInst user (programmer). If you want to play with operands directly, probably you will need lower level methods than SwitchInst ones (TerminatorInst or may be User). After this patch we can reorganize SwitchInst operands and successors as we want.
What was done:
1. Changed semantics of index inside the getCaseValue method:
getCaseValue(0) means "get first case", not a condition. Use getCondition() if you want to resolve the condition. I propose don't mix SwitchInst case indexing with low level indexing (TI successors indexing, User's operands indexing), since it may be dangerous.
2. By the same reason findCaseValue(ConstantInt*) returns actual number of case value. 0 means first case, not default. If there is no case with given value, ErrorIndex will returned.
3. Added getCaseSuccessor method. I propose to avoid usage of TerminatorInst::getSuccessor if you want to resolve case successor BB. Use getCaseSuccessor instead, since internal SwitchInst organization of operands/successors is hidden and may be changed in any moment.
4. Added resolveSuccessorIndex and resolveCaseIndex. The main purpose of these methods is to see how case successors are really mapped in TerminatorInst.
4.1 "resolveSuccessorIndex" was created if you need to level down from SwitchInst to TerminatorInst. It returns TerminatorInst's successor index for given case successor.
4.2 "resolveCaseIndex" converts low level successors index to case index that curresponds to the given successor.
Note: There are also related compatability fix patches for dragonegg, klee, llvm-gcc-4.0, llvm-gcc-4.2, safecode, clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149481 91177308-0d34-0410-b5e6-96231b3b80d8
This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure.
Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149468 91177308-0d34-0410-b5e6-96231b3b80d8
Move to a by-section allocation and relocation scheme. This allows
better support for sections which do not contain externally visible
symbols.
Flesh out the relocation address vs. local storage address separation a
bit more as well. Remote process JITs use this to tell the relocation
resolution code where the code will live when it executes.
The startFunctionBody/endFunctionBody interfaces to the JIT and the
memory manager are deprecated. They'll stick around for as long as the
old JIT does, but the MCJIT doesn't use them anymore.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148258 91177308-0d34-0410-b5e6-96231b3b80d8
Previously let the JITEmitter do it. That's rather odd, and doesn't play nice
with the MCJIT, so move the (trivial) logic up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147967 91177308-0d34-0410-b5e6-96231b3b80d8
file error checking. Use that to error on an unfinished cfi_startproc.
The error is not nice, but is already better than a segmentation fault.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147717 91177308-0d34-0410-b5e6-96231b3b80d8
properly initializing the target infos. I decided it wasn't worth linking them
in for this, so just switched back to using the Makefile variable for now. We
can reconsider later if we ever get pluggable targets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146711 91177308-0d34-0410-b5e6-96231b3b80d8
subdirectories to traverse into.
- Originally I wanted to avoid this and just autoscan, but this has one key
flaw in that new subdirectories can not automatically trigger a rerun of the
llvm-build tool. This is particularly a pain when switching back and forth
between trees where one has added a subdirectory, as the dependencies will
tend to be wrong. This will also eliminates FIXME implicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146436 91177308-0d34-0410-b5e6-96231b3b80d8
generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each
non-temporary label.
The next part will be to get the clang driver to enable this when assembling
a .s file. rdar://9275556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146262 91177308-0d34-0410-b5e6-96231b3b80d8
change, now you need a TargetOptions object to create a TargetMachine. Clang
patch to follow.
One small functionality change in PTX. PTX had commented out the machine
verifier parts in their copy of printAndVerify. That now calls the version in
LLVMTargetMachine. Users of PTX who need verification disabled should rely on
not passing the command-line flag to enable it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145714 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
llvm-config: Replace with C++ version (was llvm-config-2).
- Reapply of r144300, with lots of fixes/migration easement in between.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145582 91177308-0d34-0410-b5e6-96231b3b80d8
to the way we currently expect target selection to work -- clients are supposed
to have control over what targets are available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145331 91177308-0d34-0410-b5e6-96231b3b80d8
and code model. This eliminates the need to pass OptLevel flag all over the
place and makes it possible for any codegen pass to use this information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144788 91177308-0d34-0410-b5e6-96231b3b80d8
This will break users of the LLVMCreateDisasm API (not that I know of any). They have to call the
LLVMInitializeAll* functions from llvm-c/Target.h themselves now. edis' C API in all its horribleness
should be unaffected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144385 91177308-0d34-0410-b5e6-96231b3b80d8
- Also, fix a refacto that left extra "all" component in list (this is now
defined in the groups explicitly)
- Reapply of r143879 now that Make should see needed deps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144201 91177308-0d34-0410-b5e6-96231b3b80d8
- Also, fix a refacto that left extra "all" component in list (this is now
defined in the groups explicitly)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143879 91177308-0d34-0410-b5e6-96231b3b80d8
- Still doesn't use actual generated component table, but that is now just a matter of wiring into the build system.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143617 91177308-0d34-0410-b5e6-96231b3b80d8
for now).
- Mostly complete except for the data that needs to come from the build system
or the dependencies.
- Has some small improvements from current llvm-config:
o Uses TargetRegistry directly to get some information.
o Designed to work correctly when used from a CMake build tree (relatively
untested currently) (although pcc fixed this recently for old llvm-config).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143616 91177308-0d34-0410-b5e6-96231b3b80d8
to force it to build after all library targets so it has complete
dependency information. This should fix broken 'make install' with
CMake.
This is a partial revert of r143540, but it doesn't revert the most
important part of that change: removing the dependency edge from LLVM
tools to the llvm-config script.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143548 91177308-0d34-0410-b5e6-96231b3b80d8
-g flag. In this part we generate the .file for the source being assembled and
the .loc's for the assembled instructions.
The next part will be to generate the dwarf Compile Unit DIE and a dwarf
subprogram DIE for each non-temporary label.
Once the next part is done test cases will be added. rdar://9275556
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143509 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, if invoked from a CMake build directory, 'llvm-config
--cppflags' and friends would only print a -I flag for the build
directory's header search path, because it would assume that it was
already installed, not recognising its parent directory as being the
build directory. Teach llvm-config about CMake build directories
so that it prints a -I for both the source and build directory's
search paths.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143171 91177308-0d34-0410-b5e6-96231b3b80d8
.file filenumber "directory" "filename"
This removes one join+split of the directory+filename in MC internals. Because
bitcode files have independent fields for directory and filenames in debug info,
this patch may change the .o files written by existing .bc files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142300 91177308-0d34-0410-b5e6-96231b3b80d8
the X86 asmparser to produce ranges in the one case that was annoying me, for example:
test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
^~~~~~~
It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use
ranges where appropriate if someone is interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142106 91177308-0d34-0410-b5e6-96231b3b80d8
This line, and those below, will be ignored--
M include/llvm/Linker.h
M tools/bugpoint/Miscompilation.cpp
M tools/bugpoint/BugDriver.cpp
M tools/llvm-link/llvm-link.cpp
M lib/Linker/LinkModules.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141606 91177308-0d34-0410-b5e6-96231b3b80d8
flags as binutils objdump but the output is different, not just in format but
also showing different sections. Compare its results against readelf, not
objdump.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141579 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r141377 into '.':
U tools/llvm-objdump/MachODump.cpp
--- Reverse-merging r141376 into '.':
U include/llvm/Object/COFF.h
U include/llvm/Object/ObjectFile.h
U include/llvm-c/Object.h
U tools/llvm-objdump/llvm-objdump.cpp
U lib/Object/MachOObjectFile.cpp
U lib/Object/COFFObjectFile.cpp
U lib/Object/Object.cpp
U lib/Object/ELFObjectFile.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141379 91177308-0d34-0410-b5e6-96231b3b80d8
Add llvm-cov skeleton. It has initial support to read coverage info generated by GCOVProfiling.cpp.
Today, you can do
prompt> clang a.c -ftest-coverage -fprofile-arcs -o a
prompt> ./a
prompt> llvm-cov -gcno a.gcno -gcda a.gcda
a.c
: #include "a.h"
:
: int main() {
: int i = 0;
: if (i) {
1: int j = 0;
1: j = 1;
1: } else {
: int k = 1;
: k = 2;
: }
1: return 0;
: }
:
:
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140712 91177308-0d34-0410-b5e6-96231b3b80d8
The problems that llvmc solved have largely been subsumed with the
tasks that the clang driver can accomplish, but llvmc lacks flexibility
and depends too heavily on the EOL'd llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140093 91177308-0d34-0410-b5e6-96231b3b80d8
- It can take FunctionStarts from a binary to find entry points more accurately.
- Symbol offsets in executables are correct now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@140028 91177308-0d34-0410-b5e6-96231b3b80d8
gold plugin is built with Large File Support (sizeof(off_t) == 64 on i686)
and the rest of LLVM is built w/o Large File Support
(sizeof(off_t) == 32 on i686) which corrupts the stack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139873 91177308-0d34-0410-b5e6-96231b3b80d8
- Add enum SymbolType and function getSymbolType()
- Add function isGlobal() - it's returns true for symbols that can be used in another objects, such as library functions.
- Rename function getAddress() to getOffset() and add new function getAddress(), because currently getAddress() returns section offset of symbol first byte. new getAddress() return symbol address.
- Change usage SymbolRef::getAddress() to getOffset() in tools/llvm-nm and tools/llvm-objdump.
Patch by Danil Malyshev!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139683 91177308-0d34-0410-b5e6-96231b3b80d8
This is only one half of it, the part that caches address ranges from the DIEs when .debug_aranges is
not available will be ported soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139680 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces a new library to LLVM: libDebugInfo. It will provide debug information
parsing to LLVM. Much of the design and some of the code is taken from the LLDB project.
It also contains an llvm-dwarfdump tool that can dump the abbrevs and DIEs from an
object file. It can be used to write tests for DWARF input and output easily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139627 91177308-0d34-0410-b5e6-96231b3b80d8
edis shared library in the Makefile build, also stop building it in the
CMake build.
Patch by arrowdodger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@139108 91177308-0d34-0410-b5e6-96231b3b80d8
- On COFF the .lcomm directive has an alignment argument.
- On ELF we fall back to .local + .comm
Based on a patch by NAKAMURA Takumi.
Fixes PR9337, PR9483 and PR10128.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138976 91177308-0d34-0410-b5e6-96231b3b80d8
but it solves a layering violation since things in Support are not supposed to
use things in Transforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136726 91177308-0d34-0410-b5e6-96231b3b80d8
specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136433 91177308-0d34-0410-b5e6-96231b3b80d8
In "normal" code these only happen when disassembling data, so we
won't lose anything if we just drop them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135786 91177308-0d34-0410-b5e6-96231b3b80d8
the Support library. Now its part of the TargetRegistry, and the three
commands that care about this explicitly register this extra bit of
version information.
The set of commands which care was computed by intersecting those which
use the Support library's version string printing and those that
initialize all the registered targets in a way that produces
a meaningful list. The only odd ball out is that 'clang -cc1as -version'
no longer prints the registered targets. I don't think anyone is really
interested in that (especially as the fact that llvm-mc does so is under
a FIXME), but if someone really does want this back I'll happily apply
the same patch there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135757 91177308-0d34-0410-b5e6-96231b3b80d8
There is still a bit more refactoring left to do in Targets. But we are now very
close to fixing all the layering issues in MC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135611 91177308-0d34-0410-b5e6-96231b3b80d8
- Not great yet, but it's a start.
- Requires an object file with a symbol table. (I really want to fix this, but it'll need a whole new algorithm)
- ELF and COFF won't work at the moment due to libObject shortcomings.
To try it out run
$ llvm-objdump -d --cfg foo.o
This will create a graphviz file for every symbol in the object file's text section containing a CFG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135608 91177308-0d34-0410-b5e6-96231b3b80d8
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135580 91177308-0d34-0410-b5e6-96231b3b80d8
TargetLoweringObjectFileImpl down to MCObjectFileInfo.
TargetAsmInfo is done to one last method. It's *almost* gone!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135569 91177308-0d34-0410-b5e6-96231b3b80d8
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135468 91177308-0d34-0410-b5e6-96231b3b80d8
to MCRegisterInfo. Also initialize the mapping at construction time.
This patch eliminate TargetRegisterInfo from TargetAsmInfo. It's another step
towards fixing the layering violation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135424 91177308-0d34-0410-b5e6-96231b3b80d8
available when Clang is found within the LLVM tree. If enabled (the
default), Clang will be built as part of LLVM. If disabled, Clang will
be skipped... and can be built by configuring a separate object
directory just for Clang. This helps break up the monolithic
LLVM+Clang project that many Clang developers use, improving
build/load times.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135218 91177308-0d34-0410-b5e6-96231b3b80d8
TargetAsmInfo, which in turn pulls in TargetRegisterInfo, etc. :-( There are
other cases of violations, but this is probably the worst.
This patch is but one small step towards fixing this. 500 more steps to go. :-(
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135131 91177308-0d34-0410-b5e6-96231b3b80d8
an assert on Darwin llvm-gcc builds.
Assertion failed: (castIsValid(op, S, Ty) && "Invalid cast!"), function Create, file /Users/buildslave/zorg/buildbot/smooshlab/slave-0.8/build.llvm-gcc-i386-darwin9-RA/llvm.src/lib/VMCore/Instructions.cpp, li\
ne 2067.
etc.
http://smooshlab.apple.com:8013/builders/llvm-gcc-i386-darwin9-RA/builds/2354
--- Reverse-merging r134893 into '.':
U include/llvm/Target/TargetData.h
U include/llvm/DerivedTypes.h
U tools/bugpoint/ExtractFunction.cpp
U unittests/Support/TypeBuilderTest.cpp
U lib/Target/ARM/ARMGlobalMerge.cpp
U lib/Target/TargetData.cpp
U lib/VMCore/Constants.cpp
U lib/VMCore/Type.cpp
U lib/VMCore/Core.cpp
U lib/Transforms/Utils/CodeExtractor.cpp
U lib/Transforms/Instrumentation/ProfilingUtils.cpp
U lib/Transforms/IPO/DeadArgumentElimination.cpp
U lib/CodeGen/SjLjEHPrepare.cpp
--- Reverse-merging r134888 into '.':
G include/llvm/DerivedTypes.h
U include/llvm/Support/TypeBuilder.h
U include/llvm/Intrinsics.h
U unittests/Analysis/ScalarEvolutionTest.cpp
U unittests/ExecutionEngine/JIT/JITTest.cpp
U unittests/ExecutionEngine/JIT/JITMemoryManagerTest.cpp
U unittests/VMCore/PassManagerTest.cpp
G unittests/Support/TypeBuilderTest.cpp
U lib/Target/MBlaze/MBlazeIntrinsicInfo.cpp
U lib/Target/Blackfin/BlackfinIntrinsicInfo.cpp
U lib/VMCore/IRBuilder.cpp
G lib/VMCore/Type.cpp
U lib/VMCore/Function.cpp
G lib/VMCore/Core.cpp
U lib/VMCore/Module.cpp
U lib/AsmParser/LLParser.cpp
U lib/Transforms/Utils/CloneFunction.cpp
G lib/Transforms/Utils/CodeExtractor.cpp
U lib/Transforms/Utils/InlineFunction.cpp
U lib/Transforms/Instrumentation/GCOVProfiling.cpp
U lib/Transforms/Scalar/ObjCARC.cpp
U lib/Transforms/Scalar/SimplifyLibCalls.cpp
U lib/Transforms/Scalar/MemCpyOptimizer.cpp
G lib/Transforms/IPO/DeadArgumentElimination.cpp
U lib/Transforms/IPO/ArgumentPromotion.cpp
U lib/Transforms/InstCombine/InstCombineCompares.cpp
U lib/Transforms/InstCombine/InstCombineAndOrXor.cpp
U lib/Transforms/InstCombine/InstCombineCalls.cpp
U lib/CodeGen/DwarfEHPrepare.cpp
U lib/CodeGen/IntrinsicLowering.cpp
U lib/Bitcode/Reader/BitcodeReader.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134949 91177308-0d34-0410-b5e6-96231b3b80d8
and MCSubtargetInfo.
- Added methods to update subtarget features (used when targets automatically
detect subtarget features or switch modes).
- Teach X86Subtarget to update MCSubtargetInfo features bits since the
MCSubtargetInfo layer can be shared with other modules.
- These fixes .code 16 / .code 32 support since mode switch is updated in
MCSubtargetInfo so MC code emitter can do the right thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134884 91177308-0d34-0410-b5e6-96231b3b80d8
patch brings numerous advantages to LLVM. One way to look at it
is through diffstat:
109 files changed, 3005 insertions(+), 5906 deletions(-)
Removing almost 3K lines of code is a good thing. Other advantages
include:
1. Value::getType() is a simple load that can be CSE'd, not a mutating
union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
uniques them. This means that the compiler doesn't merge them structurally
which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead
"const Type *" everywhere.
Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.
"LLVM 3.0" is the right time to do this.
There are still some cleanups pending after this, this patch is large enough
as-is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134829 91177308-0d34-0410-b5e6-96231b3b80d8
CPU, and feature string. Parsing some asm directives can change
subtarget state (e.g. .code 16) and it must be reflected in other
modules (e.g. MCCodeEmitter). That is, the MCSubtargetInfo instance
must be shared.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134795 91177308-0d34-0410-b5e6-96231b3b80d8
- Each target asm parser now creates its own MCSubtatgetInfo (if needed).
- Changed AssemblerPredicate to take subtarget features which tablegen uses
to generate asm matcher subtarget feature queries. e.g.
"ModeThumb,FeatureThumb2" is translated to
"(Bits & ModeThumb) != 0 && (Bits & FeatureThumb2) != 0".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134678 91177308-0d34-0410-b5e6-96231b3b80d8
be the first encoded as the first feature. It then uses the CPU name to look up
features / scheduling itineray even though clients know full well the CPU name
being used to query these properties.
The fix is to just have the clients explictly pass the CPU name!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134127 91177308-0d34-0410-b5e6-96231b3b80d8
character in std::string was causing failures for a few ObjC and Obj-C++ tests
when -flto was enabled. Revision 133999 resolved this issue. Thanks Jay!
rdar://9685235
PR10210
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134017 91177308-0d34-0410-b5e6-96231b3b80d8
This was causing compile-time failures for some of the Objc and Obj-C++
benchmarks. The specific errors were of the form: "ld: duplicate symbol …"
rdar://9660124
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133955 91177308-0d34-0410-b5e6-96231b3b80d8
all over the place in different styles and variants. Standardize on two
preferred entrypoints: one that takes a StructType and ArrayRef, and one that
takes StructType and varargs.
In cases where there isn't a struct type convenient, we now add a
ConstantStruct::getAnon method (whose name will make more sense after a few
more patches land).
It would be "really really nice" if the ConstantStruct::get and
ConstantVector::get methods didn't make temporary std::vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133412 91177308-0d34-0410-b5e6-96231b3b80d8
The LSDA is a bit difficult for the non-initiated to read. Even with comments,
it's not always clear what's going on. This wraps the ASM streamer in a class
that retains the LSDA and then emits a human-readable description of what's
going on in it.
So instead of having to make sense of:
Lexception1:
.byte 255
.byte 155
.byte 168
.space 1
.byte 3
.byte 26
Lset0 = Ltmp7-Leh_func_begin1
.long Lset0
Lset1 = Ltmp812-Ltmp7
.long Lset1
Lset2 = Ltmp913-Leh_func_begin1
.long Lset2
.byte 3
Lset3 = Ltmp812-Leh_func_begin1
.long Lset3
Lset4 = Leh_func_end1-Ltmp812
.long Lset4
.long 0
.byte 0
.byte 1
.byte 0
.byte 2
.byte 125
.long __ZTIi@GOTPCREL+4
.long __ZTIPKc@GOTPCREL+4
you can read this instead:
## Exception Handling Table: Lexception1
## @LPStart Encoding: omit
## @TType Encoding: indirect pcrel sdata4
## @TType Base: 40 bytes
## @CallSite Encoding: udata4
## @Action Table Size: 26 bytes
## Action 1:
## A throw between Ltmp7 and Ltmp812 jumps to Ltmp913 on an exception.
## For type(s): __ZTIi@GOTPCREL+4 __ZTIPKc@GOTPCREL+4
## Action 2:
## A throw between Ltmp812 and Leh_func_end1 does not have a landing pad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133286 91177308-0d34-0410-b5e6-96231b3b80d8
inconsistent with autoconf, which by default set BINUTILS_INCDIR to
empty and exclude gold from target list.
Based on a patch by Haitao Li!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131229 91177308-0d34-0410-b5e6-96231b3b80d8
This change allows bugpoint to pinpoint the "opt" pass and bitcode
segment responsible for a crash caused by miscompilation. At least it
works well for me now, without having to create any custom execution
wrappers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131186 91177308-0d34-0410-b5e6-96231b3b80d8
for all symbol differences and can drop the old EmitPCRelSymbolValue
method.
This also make getExprForFDESymbol on ELF equal to the one on MachO, and it
can be made non-virtual.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130634 91177308-0d34-0410-b5e6-96231b3b80d8
- As before, there is a minor semantic change here (evidenced by the test
change) for Darwin triples that have no version component. I debated changing
the default behavior of isOSVersionLT, but decided it made more sense for
triples to be explicit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129805 91177308-0d34-0410-b5e6-96231b3b80d8
Add handling for tracking the relocations on symbols and resolving them.
Keep track of the relocations even after they are resolved so that if
the RuntimeDyld client moves the object, it can update the address and any
relocations to that object will be updated.
For our trival object file load/run test harness (llvm-rtdyld), this enables
relocations between functions located in the same object module. It should
be trivially extendable to load multiple objects with mutual references.
As a simple example, the following now works (running on x86_64 Darwin 10.6):
$ cat t.c
int bar() {
return 65;
}
int main() {
return bar();
}
$ clang t.c -fno-asynchronous-unwind-tables -o t.o -c
$ otool -vt t.o
t.o:
(__TEXT,__text) section
_bar:
0000000000000000 pushq %rbp
0000000000000001 movq %rsp,%rbp
0000000000000004 movl $0x00000041,%eax
0000000000000009 popq %rbp
000000000000000a ret
000000000000000b nopl 0x00(%rax,%rax)
_main:
0000000000000010 pushq %rbp
0000000000000011 movq %rsp,%rbp
0000000000000014 subq $0x10,%rsp
0000000000000018 movl $0x00000000,0xfc(%rbp)
000000000000001f callq 0x00000024
0000000000000024 addq $0x10,%rsp
0000000000000028 popq %rbp
0000000000000029 ret
$ llvm-rtdyld t.o -debug-only=dyld ; echo $?
Function sym: '_bar' @ 0
Function sym: '_main' @ 16
Extracting function: _bar from [0, 15]
allocated to 0x100153000
Extracting function: _main from [16, 41]
allocated to 0x100154000
Relocation at '_main' + 16 from '_bar(Word1: 0x2d000000)
Resolving relocation at '_main' + 16 (0x100154010) from '_bar (0x100153000)(pcrel, type: 2, Size: 4).
loaded '_main' at: 0x100154000
65
$
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129388 91177308-0d34-0410-b5e6-96231b3b80d8
Teach 32-bit section loading to use the Memory Manager interface, just like
the 64-bit loading does. Tidy up a few other things here and there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129138 91177308-0d34-0410-b5e6-96231b3b80d8
Start teaching the runtime Dyld interface to use the memory manager API
for allocating space. Rather than mapping directly into the MachO object,
we extract the payload for each object and copy it into a dedicated buffer
allocated via the memory manager. For now, just do Segment64, so this works
on x86_64, but not yet on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128973 91177308-0d34-0410-b5e6-96231b3b80d8
developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.
Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128910 91177308-0d34-0410-b5e6-96231b3b80d8
The JITMemory manager references LLVM IR constructs directly, while the
runtime Dyld works at a lower level and can handle objects which may not
originate from LLVM IR. Introduce a new layer for the memory manager to
handle the interface between them. For the MCJIT, this layer will be almost
entirely simply a call-through w/ translation between the IR objects and
symbol names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128851 91177308-0d34-0410-b5e6-96231b3b80d8
with the contents of CMAKE_C(XX)_FLAGS too, else `llvm-config
--c(xx)flags' doesn't tell the absolute truth.
This comes from PR9603 and is based on a patch by Ryuta Suzuki!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128727 91177308-0d34-0410-b5e6-96231b3b80d8
Now we can remove RuntimeDyld from the LLVM_LINK_COMPONENTS of
tools/lli. CMakeLists.txt LLVM_LINK_COMPONENTS shall not differ from
its companion Makefile LINK_COMPONENTS.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128069 91177308-0d34-0410-b5e6-96231b3b80d8
Also perform the required dark rituals and sacrifices to placate the buildbot
spirits. We shall see if they are appeased...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128067 91177308-0d34-0410-b5e6-96231b3b80d8
Move the dynamic linking functionality of the llvm-rtdyld program into an
ExecutionEngine support library. Update llvm-rtdyld to just load an object
file into memory, use the library to process it, then run the _main()
function, if one is found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128031 91177308-0d34-0410-b5e6-96231b3b80d8
the alias of an InstAlias instead of the thing being aliased. Because we need to
know the features that are valid for an InstAlias.
This is part of a work-in-progress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127986 91177308-0d34-0410-b5e6-96231b3b80d8
Proof-of-concept code that code-gens a module to an in-memory MachO object.
This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
for similarly conceptual work for that part) which will take the compiled
object and link it together with the rest of the system, providing back to the
JIT a table of available symbols which will be used to respond to the
getPointerTo*() queries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127916 91177308-0d34-0410-b5e6-96231b3b80d8
Factor out the 64-bit specific bits into a helper function and add an
equivalent that loads the 32-bit sections. This allows using llvm-rtdyld on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127892 91177308-0d34-0410-b5e6-96231b3b80d8
Add a bone-simple utility to load a MachO object into memory, look for
a function (main) in it, and run that function directly. This will be used
as a test and development platform for MC-JIT work regarding symbol resolution,
dynamic lookup, etc..
Code by Daniel Dunbar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127885 91177308-0d34-0410-b5e6-96231b3b80d8
functions and initializers, just report the declarations present in
the module.
The motivation is to open the way for using the lazy module parsing,
which should speed up clients that just want a symbol list (nm, ar).
This is slightly less precise, but since both -strip-dead-prototypes
and -globaldce are part of the standard pipeline, this shouldn't
change the result for clang/dragonegg produced binaries.
Any decl in an IL file was also put there because a FE expected it
to be necessary, so this should not be a problem for "-O0 -emit-llvm".
As a sanity check, I have bootstrapped clang on linux and built
firefox on both linux and darwin. A clang bootstrap on darwin
with LTO fails with or without this patch because, ironically,
the linker doesn't like the combination of dead_strip and LTO
when building libLTO.so :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127870 91177308-0d34-0410-b5e6-96231b3b80d8
uses.
The result produced by the streamer is used to give the linker more accurate
information and to add to llvm.compiler.used. The second improvement removes
the need for the user to add __attribute__((used)) to functions only used in
inline asm. The first one lets us build firefox with LTO on Darwin :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126830 91177308-0d34-0410-b5e6-96231b3b80d8
parallel with the rest of the tools directory as it depends on Clang.
This patch was first applied in r125956 and subsequently reverted in
r125964 as it broke in-tree builds. Makefile.rules was fixed up in
r126070 to handle missing optional directories for the in-tree case,
so it should be safe now to bring this patch back in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@126071 91177308-0d34-0410-b5e6-96231b3b80d8
I've been using this mode to narrow down llc unit tests. Example
custom compile script:
llc "$@"
not pygrep.py 'mul\s+r([0-9]), r\1,' < bugpoint-test-program.s
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@125096 91177308-0d34-0410-b5e6-96231b3b80d8
