| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
reports prettier.
llvm-svn: 122816
|
|
|
|
| |
llvm-svn: 122815
|
|
|
|
|
|
| |
ashr's with huge shift amounts, PR8896
llvm-svn: 122814
|
|
|
|
| |
llvm-svn: 122812
|
|
|
|
|
|
| |
makes getLeader() nonrecursive.
llvm-svn: 122811
|
|
|
|
|
|
| |
This ensures that always the recently compiled tools are picked for testing.
llvm-svn: 122810
|
|
|
|
| |
llvm-svn: 122809
|
|
|
|
| |
llvm-svn: 122808
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
tests use absolute paths to clang.
llvm-svn: 122796
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 122788
|
|
|
|
|
|
|
|
| |
PHIs of GEPs. For the moment,
have GlobalsModRef handle this conservatively by simply removing the value from its maps.
llvm-svn: 122787
|
|
|
|
| |
llvm-svn: 122786
|
|
|
|
|
|
|
| |
invalidated by stores, so they can be handled as 'simple'
operations.
llvm-svn: 122785
|
|
|
|
|
|
|
|
|
|
|
| |
prologue and epilogue if the adjustment is 8. Similarly, use pushl / popl if
the adjustment is 4 in 32-bit mode.
In the epilogue, takes care to pop to a caller-saved register that's not live
at the exit (either return or tailcall instruction).
rdar://8771137
llvm-svn: 122783
|
|
|
|
|
|
| |
triple suffix.
llvm-svn: 122779
|
|
|
|
| |
llvm-svn: 122778
|
|
|
|
|
|
|
|
|
| |
analyses to be informed when
a pointer value has potentially become escaping. Implementations can choose to either fall back to
conservative responses for that value, or may recompute their analysis to accomodate the change.
llvm-svn: 122777
|
|
|
|
| |
llvm-svn: 122773
|
|
|
|
|
|
| |
exposed. It turns out to be a latent bug in basicaa, scary.
llvm-svn: 122772
|
|
|
|
| |
llvm-svn: 122771
|
|
|
|
|
|
|
|
|
|
|
| |
(clang/include/clang/Basic/StmtNodes.td, for instance, is tablegenned
from clang/include/clang/AST/CMakeLists.txt) so it is not contained on
the list of all .td files on the current source directory which is
used as the DEPENDS of the custom command. We must add the .td file to
the DEPENDS list of the custom command. Otherwise some .inc files are
not regenerated when the corresponding .td file changes.
llvm-svn: 122768
|
|
|
|
|
|
| |
almost-but-not-quite-identical code. No intended functionality change.
llvm-svn: 122760
|
|
|
|
|
|
|
|
|
|
|
| |
that are allowed to have metadata operands are intrinsic calls,
and the only ones that take metadata currently return void.
Just reject all void instructions, which should not be value
numbered anyway. To future proof things, add an assert to the
getHashValue impl for calls to check that metadata operands
aren't present.
llvm-svn: 122759
|
|
|
|
|
|
|
|
|
|
| |
nested values, so they can change and drop to null, which can
change the hash and cause havok.
It turns out that it isn't a good idea to value number stuff
with metadata operands anyway, so... don't.
llvm-svn: 122758
|
|
|
|
| |
llvm-svn: 122754
|
|
|
|
|
|
| |
the benefit of project-based generators (VS, XCode, etc).
llvm-svn: 122749
|
|
|
|
|
|
|
| |
InstructionSimplify on instructions that didn't change since the
last time round the loop.
llvm-svn: 122745
|
|
|
|
| |
llvm-svn: 122743
|
|
|
|
|
|
|
|
|
| |
capacity on the Visited SmallPtrSet. On 403.gcc, this is about a 4.5% speedup of
CodeGenPrepare time (which itself is 10% of time spent in the backend).
This is progress towards PR8889.
llvm-svn: 122741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
improvement in the generated code, and speeds up 'opt -std-compile-opts'
compile time on 176.gcc from 24.84s to 23.2s (about 7%).
This also resolves a specific code quality issue in rdar://7352081 which
was generating poor code for:
int t(int a, int b) {
if (a & b & 1)
return a & b;
return 3;
}
llvm-svn: 122740
|
|
|
|
|
|
|
|
| |
The rationale is that after analyzing a function in the SCC, we may want to
modify it in a way that requires us to update its uses (f.e. to replace the
call with a constant) or its users (f.e. to call it with fewer arguments).
llvm-svn: 122739
|