Now we collect all of the call sites we are interested in inlining, then inline
them. This entirely avoids issues with trying to inline a call site we got by
inlining another call site. This also eliminates iterator invalidation issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12770 91177308-0d34-0410-b5e6-96231b3b80d8
extracted, and a function that contained a single top-level loop never had
the loop extracted, regardless of how much non-loop code there was.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12403 91177308-0d34-0410-b5e6-96231b3b80d8
Require 'simplified' loops, not just raw natural loops. This fixes
CodeExtractor/2004-03-13-LoopExtractorCrash.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12381 91177308-0d34-0410-b5e6-96231b3b80d8
* Be a lot more accurate about what the effects will be when inlining a call
to a function when an argument is an alloca.
* Dramatically reduce the penalty for inlining a call in a large function.
This heuristic made it almost impossible to inline a function into a large
function, no matter how small the callee is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12363 91177308-0d34-0410-b5e6-96231b3b80d8
This allows pointers to aggregate objects, whose elements are only read, to
be promoted and passed in by element instead of by reference. This can
enable a LOT of subsequent optimizations in the caller function.
It's worth pointing out that this stuff happens a LOT of C++ programs, because
objects in templates are generally passed around by reference. When these
templates are instantiated on small aggregate or scalar types, however, it is
more efficient to pass them in by value than by reference.
This transformation triggers most on C++ codes (e.g. 334 times on eon), but
does happen on C codes as well. For example, on mesa it triggers 72 times,
and on gcc it triggers 35 times. this is amazingly good considering that
we are using 'basicaa' so far.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@12202 91177308-0d34-0410-b5e6-96231b3b80d8
assume that if they don't intend to write to a global variable, that they
would mark it as constant. However, there are people that don't understand
that the compiler can do nice things for them if they give it the information
it needs.
This pass looks for blatently obvious globals that are only ever read from.
Though it uses a trivially simple "alias analysis" of sorts, it is still able
to do amazing things to important benchmarks. 253.perlbmk, for example,
contains several ***GIANT*** function pointer tables that are not marked
constant and should be. Marking them constant allows the optimizer to turn
a whole bunch of indirect calls into direct calls. Note that only a link-time
optimizer can do this transformation, but perlbmk does have several strings
and other minor globals that can be marked constant by this pass when run
from GCCAS.
176.gcc has a ton of strings and large tables that are marked constant, both
at compile time (38 of them) and at link time (48 more). Other benchmarks
give similar results, though it seems like big ones have disproportionally
more than small ones.
This pass is extremely quick and does good things. I'm going to enable it
in gccas & gccld. Not bad for 50 SLOC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@11836 91177308-0d34-0410-b5e6-96231b3b80d8
* Make the cost metric for passing constants in as arguments to functions MUCH
more accurate, by actually estimating the amount of code that will be constant
propagated away.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10136 91177308-0d34-0410-b5e6-96231b3b80d8
* Implement FuncResolve/2003-11-20-BogusResolveWarning.ll
... which eliminates a large number of annoying warnings. I know misha
will miss them though!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@10123 91177308-0d34-0410-b5e6-96231b3b80d8
pool allocator no end of trouble, and doesn't make a lot of sense anyway. This
does not solve the problem with mutually recursive functions, but they are much less common.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9828 91177308-0d34-0410-b5e6-96231b3b80d8
