these would try hard to match constants by inverting the bits
and recursively matching. There are two problems with this:
1) some patterns would match when we didn't want them to (theoretical)
2) this is insanely expensive to do, and most often pointless.
This was apparently useful in just 2 instcombine cases, which I
added code to handle explicitly. This change speeds up 'opt'
time on 176.gcc by 1% and produces bitwise identical code.
llvm-svn: 123518
early in the cleanup code and one late interlaced with the inliner. The second one is
important because inlining and other scalar optzns can unpin allocas, allowing them to
be split up and promoted. While important for performance, this is also relatively
rare, and we would previously force a (non-lazy) computation of DomFrontiers, which
happened even if nothing became unpinned.
With this patch, the first pass of scalarrepl still promotes the vast bulk of allocas
in programs, but hte second pass has changed to use SSAUpdater, which is more "sparse"
and lazy. This speeds up opt -O3 time on kimwitu++ (a c++ app) by about 1%. The
numbers are interesting: the first pass promotes ~17500 allocas. The second pass
promotes about 1600. For non-C++ codes, the compile time win should be greater,
because the second pass of scalarrepl does less.
llvm-svn: 123437
most important simplifications, as well as resolving phase ordering issues where instcombine
would inhibit important CSE'ing opportunities, for instance on BitBench/drop3.
llvm-svn: 123418
My i386 llvm-gcc nightly tester found a regression for
SingleSource/Benchmarks/McGill/chomp that a bisect blamed on 122743.
That seems strange but apparently the combination of earlycse and instcombine
did something bad. Chris says he intended to remove the instcombine pass, so
let's go ahead and try that. We'll see if there are any performance losses.
llvm-svn: 122907
It forms memset and memcpy's, and will someday form popcount and
other stuff. All of this is bad when compiling the implementation
of memset, memcpy, popcount, etc.
llvm-svn: 122854
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
limitations, this kicks in dozens of times in the 4 specfp2000 benchmarks,
and hundreds of times in the int part. It also kicks in hundreds of times
in multisource.
This kicks in right before loop deletion, which has the pleasant effect of
deleting loops that *just* do a memset.
llvm-svn: 122664
