| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 104692
|
| |
|
|
| |
llvm-svn: 104648
|
| |
|
|
| |
llvm-svn: 104644
|
| |
|
|
| |
llvm-svn: 104290
|
| |
|
|
| |
llvm-svn: 104287
|
| |
|
|
|
|
| |
top-level LSRInstance logic.
llvm-svn: 104278
|
| |
|
|
| |
llvm-svn: 104276
|
| |
|
|
|
|
| |
aren't needed.
llvm-svn: 104273
|
| |
|
|
|
|
|
|
|
| |
Changed directly instead of using a return value.
Rename FilterOutUndesirableDedicatedRegisters's Changed variable to
distinguish it from LSRInstance's Changed member.
llvm-svn: 104269
|
| |
|
|
| |
llvm-svn: 104268
|
| |
|
|
| |
llvm-svn: 104267
|
| |
|
|
| |
llvm-svn: 104263
|
| |
|
|
|
|
|
|
|
|
|
|
| |
operand on the left, the interesting operand is on the right. This
fixes a bug where LSR was failing to recognize ICmpZero uses,
which led it to be unable to reverse the induction variable in the
attached testcase.
Delete test/CodeGen/X86/stack-color-with-reg-2.ll, because its test
is extremely fragile and hard to meaningfully update.
llvm-svn: 104262
|
| |
|
|
|
|
| |
it isn't a very interesting change, it's a change nonetheless.
llvm-svn: 104260
|
| |
|
|
| |
llvm-svn: 104236
|
| |
|
|
| |
llvm-svn: 104234
|
| |
|
|
| |
llvm-svn: 104232
|
| |
|
|
|
|
|
| |
and fix a bug that valgrind noticed where the code would std::swap an
element with itself.
llvm-svn: 104225
|
| |
|
|
|
|
|
|
| |
the addressing modes don't make this trivially easy. This allows
it to avoid falling into the less precise heuristics in more
cases.
llvm-svn: 104186
|
| |
|
|
| |
llvm-svn: 104089
|
| |
|
|
|
|
| |
constants in registers which partially cancel out their immediate fields.
llvm-svn: 104088
|
| |
|
|
|
|
|
| |
of its formulae have been removed into a helper function, and also
teach it how to update the RegUseTracker.
llvm-svn: 104087
|
| |
|
|
|
|
| |
function.
llvm-svn: 104082
|
| |
|
|
| |
llvm-svn: 104080
|
| |
|
|
|
|
| |
a helper function.
llvm-svn: 104079
|
| |
|
|
| |
llvm-svn: 104078
|
| |
|
|
|
|
|
| |
is inconsistent with the BaseRegs field. It's not print's job to
assert on an invalid condition, but it can make one more obvious.
llvm-svn: 104077
|
| |
|
|
|
|
| |
confusion with LSRInstance's RegUses member.
llvm-svn: 104076
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
llvm-svn: 103495
|
| |
|
|
| |
llvm-svn: 103457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when it detects undefined behavior. llvm.trap generally codegens into some
thing really small (e.g. a 2 byte ud2 instruction on x86) and debugging this
sort of thing is "nontrivial". For example, we now compile:
void foo() { *(int*)0 = 42; }
into:
_foo:
pushl %ebp
movl %esp, %ebp
ud2
Some may even claim that this is a security hole, though that seems dubious
to me. This addresses rdar://7958343 - Optimizing away null dereference
potentially allows arbitrary code execution
llvm-svn: 103356
|
| |
|
|
|
|
|
|
|
|
|
| |
with a vector input and output into a shuffle vector. This sort of
sequence happens when the input code stores with one type and reloads
with another type and then SROA promotes to i96 integers, which make
everyone sad.
This fixes rdar://7896024
llvm-svn: 103354
|
| |
|
|
| |
llvm-svn: 103347
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LSRUse's Regs set after all pruning is done, rather than trying
to do it on the fly, which can produce an incomplete result.
This fixes a case where heuristic pruning was stripping all
formulae from a use, which led the solver to enter an infinite
loop.
Also, add a few asserts to diagnose this kind of situation.
llvm-svn: 103328
|
| |
|
|
| |
llvm-svn: 103295
|
| |
|
|
| |
llvm-svn: 103276
|
| |
|
|
| |
llvm-svn: 103266
|
| |
|
|
|
|
| |
as MachineSink, but it isn't constrained by MachineInstr-level details.
llvm-svn: 103257
|
| |
|
|
|
|
| |
This fixes the compile-time regressions seen in last night's tests.
llvm-svn: 103118
|
| |
|
|
|
|
| |
MachineSSAUpdater to avoid duplicating all the code.
llvm-svn: 103060
|
| |
|
|
|
|
|
|
| |
indirect branches in all the predecessors. This avoids unnecessarily
splitting edges in cases where load PRE is not possible anyway.
Thanks to Jakub Staszak for pointing this out.
llvm-svn: 103034
|
| |
|
|
|
|
| |
same, now that getConstant has overloads consistent with ConstantInt::get.
llvm-svn: 102965
|
| |
|
|
|
|
| |
Patch by Jakub Staszak!
llvm-svn: 102928
|
| |
|
|
|
|
|
| |
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
|