| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
and friends.
It's unnecessary and makes the generated assembly less faithful to the original source.
llvm-svn: 166440
|
| |
|
|
|
|
| |
Part of rdar://12470317
llvm-svn: 166436
|
| |
|
|
|
|
|
|
|
| |
deterministic, replace it with a DenseMap<std::pair<unsigned, unsigned>,
PHINode*> (we already have a map from BasicBlock to unsigned).
<rdar://problem/12541389>
llvm-svn: 166435
|
| |
|
|
|
|
|
| |
CodeGen in the front-end not implemented yet.
rdar://12470317
llvm-svn: 166433
|
| |
|
|
|
|
| |
Fix by Shivarama Rao <Shivarama.Rao@amd.com>
llvm-svn: 166427
|
| |
|
|
|
|
| |
bots.
llvm-svn: 166424
|
| |
|
|
|
|
|
|
|
| |
Unreachable blocks can have invalid instructions. For example,
jump threading can produce self-referential instructions in
unreachable blocks. Also, we should not be spending time
optimizing unreachable code. Fixes PR14133.
llvm-svn: 166423
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Patch by Quentin Colombet <qcolombet@apple.com>
Original description:
"""
The attached patch is the first step to have a better control on Oz related optimizations.
The Oz optimization level focuses on code size, thus I propose to add an attribute called ForceSizeOpt.
"""
llvm-svn: 166422
|
| |
|
|
| |
llvm-svn: 166410
|
| |
|
|
|
|
| |
generate a scalar-cond select (i1 as selector).
llvm-svn: 166409
|
| |
|
|
| |
llvm-svn: 166408
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
very small but very important bugfix:
bool shouldExplore(Use *U) {
Value *V = U->get();
if (isa<CallInst>(V) || isa<InvokeInst>(V))
[...]
should have read:
bool shouldExplore(Use *U) {
Value *V = U->getUser();
if (isa<CallInst>(V) || isa<InvokeInst>(V))
Fixes PR14143!
llvm-svn: 166407
|
| |
|
|
|
|
|
|
| |
deciding whether"
It broke selfhosting stage2 in several builders.
llvm-svn: 166406
|
| |
|
|
|
|
| |
calls can be marked tail.
llvm-svn: 166405
|
| |
|
|
|
|
|
|
| |
This is important for vectors of pointers because only DataLayout,
not the underlying vector type, knows how to calculate the size
of the pointers in the vector. Fixes PR14138.
llvm-svn: 166401
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LoopDependenceAnalysis."
It passes all tests, produces better results than the old code but uses the
wrong pass, LoopDependenceAnalysis, which is old and unmaintained. "Why is it
still in tree?", you might ask. The answer is obviously: "To confuse developers."
Just swapping in the new dependency pass sends the pass manager into an infinte
loop, I'll try to figure out why tomorrow.
llvm-svn: 166399
|
| |
|
|
|
|
| |
Reported by Vincent Lejeune using an out-of-tree target.
llvm-svn: 166398
|
| |
|
|
| |
llvm-svn: 166395
|
| |
|
|
| |
llvm-svn: 166393
|
| |
|
|
| |
llvm-svn: 166392
|
| |
|
|
|
|
|
|
|
|
| |
Requires a lot less code and complexity on loop-idiom's side and the more
precise analysis can catch more cases, like the one I included as a test case.
This also fixes the edge-case miscompilation from PR9481. I'm not entirely
sure that all cases are handled that the old checks handled but LDA will
certainly become smarter in the future.
llvm-svn: 166390
|
| |
|
|
|
|
|
|
| |
We used a SCEV to detect that A[X] is consecutive. We assumed that X was
the induction variable. But X can be any expression that uses the induction
for example: X = i + 2;
llvm-svn: 166388
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is important for nested-loop reductions such as :
In the innermost loop, the induction variable does not start with zero:
for (i = 0 .. n)
for (j = 0 .. m)
sum += ...
llvm-svn: 166387
|
| |
|
|
|
|
| |
of the pass.
llvm-svn: 166386
|
| |
|
|
| |
llvm-svn: 166384
|
| |
|
|
|
|
| |
PR14134.
llvm-svn: 166379
|
| |
|
|
|
|
| |
functions static.
llvm-svn: 166376
|
| |
|
|
| |
llvm-svn: 166375
|
| |
|
|
|
|
|
|
| |
ConstantFoldInstOperands and crash.
Have to refactor the ConstantFolder interface one day to define bugs like this away. Fixes PR14131.
llvm-svn: 166374
|
| |
|
|
|
|
|
|
|
| |
A[B[i]]+=x.
If the pointer is consecutive then it is safe to read and write. If the pointer is non-loop-consecutive then
it is unsafe to vectorize it because we may hit an ordering issue.
llvm-svn: 166371
|
| |
|
|
| |
llvm-svn: 166367
|
| |
|
|
|
|
| |
change.
llvm-svn: 166366
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 166360
|
| |
|
|
|
|
| |
inline assembly. Also make sure the remove the ignored statements from the IR.
llvm-svn: 166357
|
| |
|
|
| |
llvm-svn: 166354
|
| |
|
|
| |
llvm-svn: 166352
|
| |
|
|
|
|
|
|
|
| |
For example:
for (i=0; i<n; i++)
sum += A[i] + B[i] + i;
llvm-svn: 166351
|
| |
|
|
|
|
|
|
| |
(The change at Clang side was committed in r166345)
2. Cosmetic change in order to conform to coding standards.
llvm-svn: 166350
|
| |
|
|
| |
llvm-svn: 166349
|
| |
|
|
| |
llvm-svn: 166344
|
| |
|
|
|
|
|
| |
Currently, it is enabled only if option "enable-mips-tail-calls" is given and
all of the callee's arguments are passed in registers.
llvm-svn: 166342
|
| |
|
|
| |
llvm-svn: 166341
|
| |
|
|
| |
llvm-svn: 166340
|
| |
|
|
| |
llvm-svn: 166339
|
| |
|
|
| |
llvm-svn: 166338
|
| |
|
|
| |
llvm-svn: 166337
|
| |
|
|
| |
llvm-svn: 166318
|
| |
|
|
|
|
|
| |
a memory operand. Retain this information and then add the sizing directives
to the IR. This allows the backend to do proper instruction selection.
llvm-svn: 166316
|
| |
|
|
|
|
|
|
| |
input is zero.
Fixes PR13028.
llvm-svn: 166313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_debugtrap()
which is supposed to consistently raise SIGTRAP across all systems. In contrast,
__builtin_trap() behave differently on different systems. e.g. it raises SIGTRAP on ARM, and
SIGILL on X86. The purpose of __builtin_debugtrap() is to consistently provide "trap"
functionality, in the mean time preserve the compatibility with on gcc on __builtin_trap().
The X86 backend is already able to handle debugtrap(). This patch is to:
1) make front-end recognize "__builtin_debugtrap()" (emboddied in the one-line change to Clang).
2) In DAG legalization phase, by default, "debugtrap" will be replaced with "trap", which
make the __builtin_debugtrap() "available" to all existing ports without the hassle of
changing their code.
3) If trap-function is specified (via -trap-func=xyz to llc), both __builtin_debugtrap() and
__builtin_trap() will be expanded into the function call of the specified trap function.
This behavior may need change in the future.
The provided testing-case is to make sure 2) and 3) are working for ARM port, and we
already have a testing case for x86.
llvm-svn: 166300
|