llvm-svn: 8920

llvm-svn: 8917

everything.

llvm-svn: 8916

llvm-svn: 8915

llvm-svn: 8914

llvm-svn: 8901

* Added blurb about `bugpoint'
* Fixed some grammar issues
* Added blurb about `llvm-link'
* Took out the part about the `lli debugger' which disappeared

llvm-svn: 8900

Thanks to Brian for fixing this obvious oops

llvm-svn: 8899

llvm-svn: 8898

llvm-svn: 8897

llvm-svn: 8896

llvm-svn: 8895

llvm-svn: 8894

of callees between executions.

On eon, in release mode, this changes the inliner from taking 11.5712s
to taking 2.2066s.  In debug mode, it went from taking 14.4148s to
taking 7.0745s.  In release mode, this is a 24.7% speedup of gccas, in
debug mode, it's a total speedup of 11.7%.

This also makes it slightly more aggressive.  This could be because we
are not judging the size of the functions quite as accurately as before.
When we start looking at the performance of the generated code, this can
be investigated further.

llvm-svn: 8893

llvm-svn: 8892

llvm-svn: 8891

Running the inliner on 252.eon used to take 48.4763s, now it takes 14.4148s.

In release mode, it went from taking 25.8741s to taking 11.5712s.

This also fixes a FIXME.

llvm-svn: 8890

llvm-svn: 8889

llvm-svn: 8888

want you to include <sys/stat.h> for fstat(), struct stat, and friends.

llvm-svn: 8887

llvm-svn: 8886

llvm-svn: 8885

"minimal" SSA form (in other words, it doesn't insert dead PHIs).  This
speeds up the mem2reg pass very significantly because it doesn't have to
do a lot of frivolous work in many common cases.

In the 252.eon function I have been playing with, this doesn't even insert
the 120 PHI nodes that it used to which were trivially dead (in the process
of promoting 356 alloca instructions overall).  This speeds up the mem2reg
pass from 1.2459s to 0.1284s.  More significantly, the DCE pass used to take
2.4138s to remove the 120 dead PHI nodes that mem2reg constructed, now it
takes 0.0134s (which is the time to scan the function and decide that there
is nothing dead).  So overall, on this one function, we speed things up a
total of 3.5179s, which is a 24.8x speedup!  :)

This change is tested by the Mem2Reg/2003-10-05-DeadPHIInsertion.ll test,
which now passes.

llvm-svn: 8884

llvm-svn: 8883

llvm-svn: 8882

basic block.  This is amazingly common in code generated by the C/C++ front-ends.
This change makes it not have to insert ANY phi nodes, whereas before it would insert
a ton of dead ones which DCE would have to clean up.

Thus, this fix improves compile-time performance of these trivial allocas in two ways:
  1. It doesn't have to do the walking and book-keeping for renaming
  2. It does not insert dead phi nodes for them which would have to
     subsequently be cleaned up.

On my favorite testcase from 252.eon, this special case handles 305 out of
356 promoted allocas in the function.  It speeds up the mem2reg pass from 7.5256s
to 1.2505s.  It inserts 677 fewer dead PHI nodes, which speeds up a subsequent
-dce pass from 18.7524s to 2.4806s.

There are still 120 trivially dead PHI nodes being inserted for variables used
in multiple basic blocks, but they are not handled by this patch.

llvm-svn: 8881

llvm-svn: 8880

llvm-svn: 8879

Move support/tools into utils

llvm-svn: 8878

llvm-svn: 8876

llvm-svn: 8875

llvm-svn: 8874

llvm-svn: 8873

llvm-svn: 8872

llvm-svn: 8871

functionpass

llvm-svn: 8870

do not support stack unwinding yet

llvm-svn: 8869

llvm-svn: 8868

This reduces the time to verify a function from eon with a large number of
large PHI nodes from 22996s (6.38 hours) to 10.5499s

llvm-svn: 8866

llvm-svn: 8865