| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
the worklist, making them inline candidates.
llvm-svn: 102213
|
| |
|
|
|
|
|
|
|
| |
This fixes a bug where calls inlined into an invoke would get
changed into an invoke but the array would keep pointing to
the (now dead) call. The improved inliner behavior is still
disabled for now.
llvm-svn: 102196
|
| |
|
|
| |
llvm-svn: 102153
|
| |
|
|
|
|
|
|
|
|
| |
that appear in the SCC as a result of inlining as candidates
for inlining. Change this so that it *does* consider call
sites that change from being indirect to being direct as a
result of inlining. This allows it to completely
"devirtualize" the testcase.
llvm-svn: 102146
|
| |
|
|
|
|
|
|
| |
arguments are handled with a new InlineFunctionInfo class. This
makes it easier to extend InlineFunction to return more info in the
future.
llvm-svn: 102137
|
| |
|
|
| |
llvm-svn: 101899
|
| |
|
|
| |
llvm-svn: 101846
|
| |
|
|
|
|
|
|
| |
Arg promotion was deleting call graph nodes that still had references
from the 'indirect' CGN. Like the inliner, it should only delete the
function if all references are gone.
llvm-svn: 101845
|
| |
|
|
|
|
|
| |
Probably the best way to know that all getOperand() calls have been handled
is to replace that API instead of updating.
llvm-svn: 101579
|
| |
|
|
|
|
|
|
| |
to CallGraphSCCPass's instead of passing around a
std::vector<CallGraphNode*>. No functionality change,
but now we have a much tidier interface.
llvm-svn: 101558
|