| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
works only on MinGW32. On 64-bit, the function to call is "__chkstk".
Patch by KS Sreeram!
llvm-svn: 122934
|
| |
|
|
|
|
|
|
| |
beginning of the "main" function. The assembler complains about the invalid
suffix for the 'call' instruction. The right instruction is "callq __main".
Patch by KS Sreeram!
llvm-svn: 122933
|
| |
|
|
|
|
| |
worklist, the key will need to become std::pair<BasicBlock*, Value*>.
llvm-svn: 122932
|
| |
|
|
| |
llvm-svn: 122929
|
| |
|
|
|
|
|
|
|
| |
r1025 = s/zext r1024, 4
r1026 = extract_subreg r1025, 4
to:
r1026 = copy r1024
llvm-svn: 122925
|
| |
|
|
| |
llvm-svn: 122921
|
| |
|
|
| |
llvm-svn: 122920
|
| |
|
|
|
|
| |
calculated.
llvm-svn: 122912
|
| |
|
|
| |
llvm-svn: 122911
|
| |
|
|
| |
llvm-svn: 122909
|
| |
|
|
|
|
|
|
| |
compute the value range
in the predecessor block, leading to an incorrect conclusion for the edge value. Found by inspection.
llvm-svn: 122908
|
| |
|
|
|
|
|
|
|
| |
fix the issue in
hasBlockValue() that was causing iterator invalidations. Many thanks to Dimitry Andric for
tracking down those invalidations!
llvm-svn: 122906
|
| |
|
|
| |
llvm-svn: 122893
|
| |
|
|
| |
llvm-svn: 122891
|
| |
|
|
|
|
| |
by overriding TargetFrameInfo::getFrameIndexOffset to take into account the new frame index information.
llvm-svn: 122889
|
| |
|
|
|
|
| |
regressing code quality.
llvm-svn: 122887
|
| |
|
|
| |
llvm-svn: 122884
|
| |
|
|
| |
llvm-svn: 122883
|
| |
|
|
| |
llvm-svn: 122882
|
| |
|
|
| |
llvm-svn: 122881
|
| |
|
|
| |
llvm-svn: 122879
|
| |
|
|
| |
llvm-svn: 122876
|
| |
|
|
|
|
|
| |
step is to only process instructions in subloops if they have been modified by
an earlier simplification.
llvm-svn: 122869
|
| |
|
|
|
|
|
|
|
|
| |
skipping them, but it should probably use a worklist and only revisit those
instructions in subloops that have actually changed. It should probably also
use a worklist after the first iteration like instsimplify now does. Regardless,
it's only 0.3% of opt -O2 time on 403.gcc if it replaces the instcombine placed
in the middle of the loop passes.
llvm-svn: 122868
|
| |
|
|
| |
llvm-svn: 122849
|
| |
|
|
|
|
|
|
|
| |
this should allow us to insert
fewer things into the value numbering maps, but any speedup is beneath the noise threshold on my machine
on 403.gcc.
llvm-svn: 122844
|
| |
|
|
|
|
| |
bundles in the pass.
llvm-svn: 122833
|
| |
|
|
|
|
|
|
|
|
| |
The analysis will be needed by both the greedy register allocator and the
X86FloatingPoint pass. It only needs to be computed once when the CFG doesn't
change.
This pass is very fast, usually showing up as 0.0% wall time.
llvm-svn: 122832
|
| |
|
|
|
|
| |
warning is overzealous but gcc is what it is.)
llvm-svn: 122829
|
| |
|
|
| |
llvm-svn: 122828
|
| |
|
|
| |
llvm-svn: 122827
|
| |
|
|
| |
llvm-svn: 122826
|
| |
|
|
|
|
|
|
| |
the "leader table", and
rename methods to make it much more clear what they're doing.
llvm-svn: 122823
|
| |
|
|
|
|
| |
in a corner case.
llvm-svn: 122822
|
| |
|
|
|
|
|
|
|
|
| |
case where a static caller is itself inlined everywhere else, and
thus may go away if it doesn't get too big due to inlining other
things into it. If there are references to the caller other than
calls, it will not be removed; account for this.
This results in same-day completion of the case in PR8853.
llvm-svn: 122821
|
| |
|
|
|
|
|
|
|
| |
value number for them. This
avoids adding them to the various value numbering tables, resulting in a minor (~3%) speedup for GVN
on 40.gcc.
llvm-svn: 122819
|
| |
|
|
| |
llvm-svn: 122817
|
| |
|
|
| |
llvm-svn: 122815
|
| |
|
|
|
|
| |
ashr's with huge shift amounts, PR8896
llvm-svn: 122814
|
| |
|
|
|
|
| |
makes getLeader() nonrecursive.
llvm-svn: 122811
|
| |
|
|
| |
llvm-svn: 122809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when safe.
The testcase is basically this nested loop:
void foo(char *X) {
for (int i = 0; i != 100; ++i)
for (int j = 0; j != 100; ++j)
X[j+i*100] = 0;
}
which gets turned into a single memset now. clang -O3 doesn't optimize
this yet though due to a phase ordering issue I haven't analyzed yet.
llvm-svn: 122806
|
| |
|
|
|
|
|
|
| |
instruction *after* the store. The store will always be deleted
if the transformation kicks in, so we'd do an N^2 scan of every
loop block. Whoops.
llvm-svn: 122805
|
| |
|
|
|
|
| |
spent in StrongPHIElimination on 403.gcc.
llvm-svn: 122803
|
| |
|
|
|
|
| |
CodeGenPrepare (which is the default behavior).
llvm-svn: 122801
|
| |
|
|
|
|
| |
static constructors.
llvm-svn: 122795
|
| |
|
|
| |
llvm-svn: 122794
|
| |
|
|
|
|
|
|
|
|
|
|
| |
FunctionPass. It probably doesn't have a reason to be a LoopPass, as it will
probably drop the simple fixed point and either use RPO iteration or Duncan's
approach in instsimplify of only revisiting instructions that have changed.
The next step is to preserve LoopSimplify. This looks like it won't be too hard,
although the pass manager doesn't actually seem to respect when non-loop passes
claim to preserve LCSSA or LoopSimplify. This will have to be fixed.
llvm-svn: 122791
|
| |
|
|
|
|
|
| |
stop setting NSW: signed overflow is possible. Thanks to Dan
for pointing these out.
llvm-svn: 122790
|
| |
|
|
| |
llvm-svn: 122789
|