| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 109103
|
| |
|
|
| |
llvm-svn: 109101
|
| |
|
|
|
|
| |
use_iterators
llvm-svn: 109100
|
| |
|
|
| |
llvm-svn: 109099
|
| |
|
|
| |
llvm-svn: 109092
|
| |
|
|
| |
llvm-svn: 109045
|
| |
|
|
| |
llvm-svn: 108968
|
| |
|
|
| |
llvm-svn: 108962
|
| |
|
|
| |
llvm-svn: 108961
|
| |
|
|
|
|
| |
avoiding MDNode overhead.
llvm-svn: 108909
|
| |
|
|
|
|
| |
so there is no locking involved in type refinement.
llvm-svn: 108553
|
| |
|
|
| |
llvm-svn: 108517
|
| |
|
|
| |
llvm-svn: 108418
|
| |
|
|
| |
llvm-svn: 108417
|
| |
|
|
| |
llvm-svn: 108252
|
| |
|
|
| |
llvm-svn: 108146
|
| |
|
|
| |
llvm-svn: 108145
|
| |
|
|
| |
llvm-svn: 108144
|
| |
|
|
| |
llvm-svn: 108143
|
| |
|
|
| |
llvm-svn: 108134
|
| |
|
|
|
|
| |
by Hans Vandierendonck from PR7605
llvm-svn: 108116
|
| |
|
|
| |
llvm-svn: 107990
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
builds to "Release". The default build is unchanged (optimization on,
assertions on), however it is now called Release+Asserts. The intent
is that future LLVM releases released via llvm.org will be Release builds
in the new sense, i.e. will have assertions disabled (currently they have
assertions enabled, for a more than 20% slowdown). This will bring them
in line with MacOS releases, which ship with assertions disabled. It also
means that "Release" now means the same things in make and cmake builds:
cmake already disables assertions for "Release" builds AFAICS.
llvm-svn: 107758
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C metadata types which should be marked as "weak", but which the
linker will remove upon final linkage. However, this linkage isn't specific to
Objective-C.
For example, the "objc_msgSend_fixup_alloc" symbol is defined like this:
.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1
This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".
Currently only supported on Darwin platforms.
llvm-svn: 107433
|
| |
|
|
|
|
|
|
|
| |
such a way that debug info for symbols preserved even if symbols are
optimized away by the optimizer.
Add new special pass to remove debug info for such symbols.
llvm-svn: 107416
|
| |
|
|
| |
llvm-svn: 107412
|
| |
|
|
| |
llvm-svn: 107323
|
| |
|
|
| |
llvm-svn: 107277
|
| |
|
|
| |
llvm-svn: 107215
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata types which should be marked as "weak", but which the linker will
remove upon final linkage. For example, the "objc_msgSend_fixup_alloc" symbol is
defined like this:
.globl l_objc_msgSend_fixup_alloc
.weak_definition l_objc_msgSend_fixup_alloc
.section __DATA, __objc_msgrefs, coalesced
.align 3
l_objc_msgSend_fixup_alloc:
.quad _objc_msgSend_fixup
.quad L_OBJC_METH_VAR_NAME_1
This is different from the "linker_private" linkage type, because it can't have
the metadata defined with ".weak_definition".
llvm-svn: 107205
|
| |
|
|
|
|
|
|
| |
is stripped off. Currently set unconditionally, since the API
does not provide a way of working out if anything was actually
stripped off.
llvm-svn: 107142
|
| |
|
|
|
|
| |
perform some cosmetics
llvm-svn: 106747
|
| |
|
|
| |
llvm-svn: 106745
|
| |
|
|
|
|
| |
The ValueMapper used by various cloning utility maps MDNodes also.
llvm-svn: 106706
|
| |
|
|
| |
llvm-svn: 106542
|
| |
|
|
| |
llvm-svn: 105551
|
| |
|
|
|
|
| |
using the same constants as the specialization, leading to calls to the wrong specialization. Patch by Takumi Nakamura\!
llvm-svn: 105528
|
| |
|
|
| |
llvm-svn: 105220
|
| |
|
|
| |
llvm-svn: 104236
|
| |
|
|
|
|
|
| |
inliner did in r103653. Why does the always inliner even bother with cost
estimates anyways?
llvm-svn: 103858
|
| |
|
|
| |
llvm-svn: 103857
|
| |
|
|
| |
llvm-svn: 103700
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector<>::push_back() in:
int foo(vector<int> &a, vector<unsigned> &b) {
a.push_back(10);
b.push_back(11);
}
to two calls to the same push_back function, or fold away the two copies of
push_back() in:
struct T { int; };
struct S { char; };
vector<T*> t;
vector<S*> s;
void f(T *x) { t.push_back(x); }
void g(S *x) { s.push_back(x); }
but leave f() and g() separate, since they refer to two different global
variables.
llvm-svn: 103698
|
| |
|
|
|
|
|
|
|
|
| |
on RAUW of functions, this is a correctness issue instead of a mere memory
usage problem.
No testcase until the new MergeFunctions can land.
llvm-svn: 103653
|
| |
|
|
|
|
|
| |
other places, killing a valid transformation is not the right
answer.
llvm-svn: 102850
|
| |
|
|
|
|
|
|
|
|
| |
halting analysis, it is illegal to delete a call to a read-only function.
The correct solution is almost certainly to add a "must halt" attribute and
only allow deletions in its presence.
XFAIL the relevant testcase for now.
llvm-svn: 102831
|
| |
|
|
|
|
|
| |
reflect that it includes all inlined calls now, not just
devirtualized ones.
llvm-svn: 102824
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that appear due to inlining a callee as candidates for
futher inlining, but a recent patch made it do this if
those call sites were indirect and became direct.
Unfortunately, in bizarre cases (see testcase) doing this
can cause us to infinitely inline mutually recursive
functions into callers not in the cycle. Fix this by
keeping track of the inline history from which callsite
inline candidates got inlined from.
This shouldn't affect any "real world" code, but is required
for a follow on patch that is coming up next.
llvm-svn: 102822
|
| |
|
|
|
|
|
|
| |
argument.
Radar 7927803
llvm-svn: 102760
|
| |
|
|
| |
llvm-svn: 102296
|