| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
doFinalization per module detangled from runOn?? calls, still has temporary code not to break ASAN to be removed when that pass conforms to the proposed model
Patch by Pedro Artigas, with feedback from by Chandler Carruth.
llvm-svn: 168635
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Necessary to give disassembler users (like darwin's otool) a possibility to
dlopen libLTO and still initialize the required LLVM bits. This used to go
through libMCDisassembler but that's a gross layering violation, the MC layer
can't pull in functions from the targets. Adding a function to libLTO is a bit
of a hack but not worse than exposing other disassembler bits from libLTO.
Fixes PR14362.
llvm-svn: 168545
|
| |
|
|
|
|
|
|
| |
them to be re-initialized and reused on multiple Module's.
Patch by Pedro Artigas.
llvm-svn: 168008
|
| |
|
|
|
|
|
|
|
|
|
| |
Per the October 12, 2012 Proposal for annotated disassembly output sent out by
Jim Grosbach this set of changes implements this for X86 and arm. The llvm-mc
tool now has a -mdis option to produced the marked up disassembly and a couple
of small example test cases have been added.
rdar://11764962
llvm-svn: 166445
|
| |
|
|
|
|
| |
Lowerinvoke.
llvm-svn: 166248
|
| |
|
|
|
|
|
|
|
|
|
| |
The TargetTransform changes are breaking LTO bootstraps of clang. I am
working with Nadav to figure out the problem, but I am reverting it for now
to get our buildbots working.
This reverts svn commits: 165665 165669 165670 165786 165787 165997
and I have also reverted clang svn 165741
llvm-svn: 166168
|
| |
|
|
| |
llvm-svn: 165997
|
| |
|
|
|
|
|
|
| |
This is a temporary hack until Bill's project to record command line options
in the LLVM IR is ready. Clang currently sets a default CPU but that isn't
recorded anywhere and it doesn't get used in the final LTO compilation.
llvm-svn: 165809
|
| |
|
|
| |
llvm-svn: 165599
|
| |
|
|
|
|
| |
This reverts commit 165428 in an attempt to get our buildbots going.
llvm-svn: 165574
|
| |
|
|
| |
llvm-svn: 165428
|
| |
|
|
| |
llvm-svn: 165403
|
| |
|
|
|
|
| |
file name if building Apple-style.
llvm-svn: 165185
|
| |
|
|
|
|
| |
<rdar://problem/12184899>
llvm-svn: 163349
|
| |
|
|
| |
llvm-svn: 163258
|
| |
|
|
|
|
| |
PR9673
llvm-svn: 162284
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make it more consistent with its intended semantics.
The `linker_private_weak_def_auto' linkage type was meant to automatically hide
globals which never had their addresses taken. It has nothing to do with the
`linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
among other things.
The intended semantic is more like the `linkonce_odr' linkage type.
Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
changing the semantics so that it produces the correct output for the linker.
Note: The old linkage name `linker_private_weak_def_auto' will still parse but
is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
<rdar://problem/11754934>
llvm-svn: 162114
|
| |
|
|
| |
llvm-svn: 161530
|
| |
|
|
| |
llvm-svn: 161529
|
| |
|
|
| |
llvm-svn: 161356
|
| |
|
|
|
|
|
|
|
| |
When the command line target options were removed from the LLVM libraries, LTO
lost its ability to specify things like `-disable-fp-elim'. Add this back by
adding the command line variables to the `lto' project.
<rdar://problem/12038729>
llvm-svn: 161353
|
| |
|
|
| |
llvm-svn: 159028
|
| |
|
|
|
|
|
|
| |
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.
llvm-svn: 158090
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
llvm-svn: 157705
|
| |
|
|
| |
llvm-svn: 156606
|
| |
|
|
|
|
|
|
|
| |
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.
llvm-svn: 154807
|
| |
|
|
|
|
| |
run that pass by default in LTO.
llvm-svn: 154356
|
| |
|
|
|
|
| |
may be some which are used in that function.
llvm-svn: 154348
|
| |
|
|
|
|
| |
ization/
llvm-svn: 154312
|
| |
|
|
| |
llvm-svn: 154306
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 154124
|
| |
|
|
| |
llvm-svn: 153928
|
| |
|
|
| |
llvm-svn: 153902
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 153870
|
| |
|
|
|
|
|
| |
definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.
llvm-svn: 153859
|
| |
|
|
| |
llvm-svn: 153810
|
| |
|
|
| |
llvm-svn: 153809
|
| |
|
|
| |
llvm-svn: 153808
|
| |
|
|
| |
llvm-svn: 153807
|
| |
|
|
| |
llvm-svn: 153805
|
| |
|
|
| |
llvm-svn: 153804
|
| |
|
|
| |
llvm-svn: 153803
|
| |
|
|
| |
llvm-svn: 153802
|
| |
|
|
|
|
|
| |
into the function.
* Reorder some header files.
llvm-svn: 153783
|
| |
|
|
| |
llvm-svn: 153740
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 153638
|
| |
|
|
| |
llvm-svn: 153634
|
| |
|
|
| |
llvm-svn: 153632
|
| |
|
|
| |
llvm-svn: 153612
|
| |
|
|
| |
llvm-svn: 153598
|