| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
is reversed from what seems intuitive to me.
llvm-svn: 143035
|
| |
|
|
| |
llvm-svn: 143034
|
| |
|
|
|
|
| |
relocations, so that we can recognize scattered relocations.
llvm-svn: 143033
|
| |
|
|
|
|
| |
require 33 bits of type info.
llvm-svn: 143032
|
| |
|
|
| |
llvm-svn: 143031
|
| |
|
|
|
|
| |
true: (x *nsw x) sgt 0, where x = (y | 1). This occurs in 464.h264ref.
llvm-svn: 143028
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trying to legalize the operand types when only the result type
is required to be legalized - the type legalization machinery
will get round to the operands later if they need legalizing.
There can be a point to legalizing operands in parallel with
the result: when this saves compile time or results in better
code. There was only one case in which this was true: when
the operand is also split, so keep the logic for that bit.
As a result of this change, additional operand legalization
methods may need to be introduced to handle nodes where the
result and operand types can differ, like SIGN_EXTEND, but
the testsuite doesn't contain any tests where this is the case.
In any case, it seems better to require such methods (and die
with an assert if they doesn't exist) than to quietly produce
wrong code if we forgot to special case the node in
SplitVecRes_UnaryOp.
llvm-svn: 143026
|
| |
|
|
|
|
| |
llvm-commits regarding exactly how much optsize should optimize for size over performance.
llvm-svn: 143023
|
| |
|
|
|
|
| |
the 'removeSuccessor' call. Noticed in a Release+Asserts+Check buildbot.
llvm-svn: 143018
|
| |
|
|
| |
llvm-svn: 143011
|
| |
|
|
|
|
|
|
|
|
|
| |
This code makes different decisions when compiled into x87 instructions
because of different rounding behavior. That caused phase 2/3
miscompares on 32-bit Linux when the phase 1 compiler was built with gcc
(using x87), and the phase 2 compiler was built with clang (using SSE).
This fixes PR11200.
llvm-svn: 143006
|
| |
|
|
|
|
| |
Devang has fixed other issues.
llvm-svn: 143003
|
| |
|
|
|
|
|
| |
on Darwin platforms where -Os means optimize for size without hurting
performance.
llvm-svn: 143002
|
| |
|
|
|
|
|
|
|
|
|
|
| |
An MBB which branches to an EH landing pad shouldn't be considered for tail merging.
In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>
llvm-svn: 143001
|
| |
|
|
|
|
|
| |
fix up later. For this special case, allow such a mask to be considered valid.
<rdar://problem/8622574>
llvm-svn: 142992
|
| |
|
|
| |
llvm-svn: 142983
|
| |
|
|
| |
llvm-svn: 142981
|
| |
|
|
| |
llvm-svn: 142970
|
| |
|
|
|
|
|
|
| |
relocation entries that are used as additional information for other, real relocations, rather than being relocations themselves.
I'm not familiar enough with ELF or COFF to know if they should have any relocations marked hidden.
llvm-svn: 142961
|
| |
|
|
| |
llvm-svn: 142959
|
| |
|
|
|
|
| |
PR11217.
llvm-svn: 142956
|
| |
|
|
| |
llvm-svn: 142938
|
| |
|
|
|
|
|
|
| |
This first patch is for expression variable kinds.
Patch by Jack Carter!
llvm-svn: 142934
|
| |
|
|
|
|
|
|
| |
The address for $sp, and addresses for sdc1/ldc1 must be 8-byte aligned
Patch by Petar Jovanovic.
llvm-svn: 142930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
down to this commit. Original commit message:
An MBB which branches to an EH landing pad shouldn't be considered for tail merging.
In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>
llvm-svn: 142920
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bots. Original commit messages:
- Reapply r142781 with fix. Original message:
Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
loop header when computing the trip count.
With this, we now constant evaluate:
struct ListNode { const struct ListNode *next; int i; };
static const struct ListNode node1 = {0, 1};
static const struct ListNode node2 = {&node1, 2};
static const struct ListNode node3 = {&node2, 3};
int test() {
int sum = 0;
for (const struct ListNode *n = &node3; n != 0; n = n->next)
sum += n->i;
return sum;
}
- Now that we look at all the header PHIs, we need to consider all the header PHIs
when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
torture testsuite!
llvm-svn: 142919
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classifying many edges as exiting which were in fact not. These mainly
formed edges into sub-loops. It was also not correctly classifying all
returning edges out of loops as leaving the loop. With this match most
of the loop heuristics are more rational.
Several serious regressions on loop-intesive benchmarks like perlbench's
loop tests when built with -enable-block-placement are fixed by these
updated heuristics. Unfortunately they in turn uncover some other
regressions. There are still several improvemenst that should be made to
loop heuristics including trip-count, and early back-edge management.
llvm-svn: 142917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the dragonegg and llvm-gcc self-host buildbots. Original commit
messages:
- Reapply r142781 with fix. Original message:
Enhance SCEV's brute force loop analysis to handle multiple PHI nodes in the
loop header when computing the trip count.
With this, we now constant evaluate:
struct ListNode { const struct ListNode *next; int i; };
static const struct ListNode node1 = {0, 1};
static const struct ListNode node2 = {&node1, 2};
static const struct ListNode node3 = {&node2, 3};
int test() {
int sum = 0;
for (const struct ListNode *n = &node3; n != 0; n = n->next)
sum += n->i;
return sum;
}
- Now that we look at all the header PHIs, we need to consider all the header PHIs
when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
torture testsuite!
llvm-svn: 142916
|
| |
|
|
| |
llvm-svn: 142912
|
| |
|
|
| |
llvm-svn: 142892
|
| |
|
|
|
|
|
|
|
|
|
|
| |
merging.
In SjLj EH, the jump to the landing pad is not done explicitly through a branch
statement. The EH landing pad is added as a successor to the throwing
BB. Because of that however, the branch folding pass could mistakenly think that
it could merge the throwing BB with another BB. This isn't safe to do.
<rdar://problem/10334833>
llvm-svn: 142891
|
| |
|
|
|
|
| |
Four entry register lists.
llvm-svn: 142882
|
| |
|
|
| |
llvm-svn: 142880
|
| |
|
|
| |
llvm-svn: 142878
|
| |
|
|
| |
llvm-svn: 142877
|
| |
|
|
|
|
| |
Three entry register list variation.
llvm-svn: 142876
|
| |
|
|
|
|
| |
for x86 and x86_64 relocations with addends.
llvm-svn: 142875
|
| |
|
|
| |
llvm-svn: 142871
|
| |
|
|
|
|
|
| |
table. A hidden variable could potentially end up in both lists.
<rdar://problem/10336715>
llvm-svn: 142869
|
| |
|
|
| |
llvm-svn: 142867
|
| |
|
|
|
|
| |
One and two length register list variants.
llvm-svn: 142861
|
| |
|
|
|
|
|
|
| |
Split am6offset into fixed and register offset variants so the instruction
encodings are explicit rather than relying an a magic reg0 marker.
Needed to being able to parse these.
llvm-svn: 142853
|
| |
|
|
| |
llvm-svn: 142852
|
| |
|
|
|
|
|
| |
when deciding that the loop has stopped evolving. Fixes miscompile in the gcc
torture testsuite!
llvm-svn: 142843
|
| |
|
|
|
|
| |
PR11207.
llvm-svn: 142841
|
| |
|
|
| |
llvm-svn: 142840
|
| |
|
|
| |
llvm-svn: 142822
|
| |
|
|
| |
llvm-svn: 142821
|
| |
|
|
|
|
| |
more of this code gets refactored, a lot of these manual decoding hooks should get smaller and/or go away entirely.
llvm-svn: 142817
|
| |
|
|
|
|
|
| |
physreg dependencies, and upcoming codegen changes will require proper
physreg dependence handling.
llvm-svn: 142816
|