llvm-svn: 11277

llvm-svn: 11276

llvm-svn: 11274

passed into main, make sure they use the return value of the init call
instead of the one passed in.

llvm-svn: 11262

I will observe that the concept of using WriteAsOperand is completely broken,
but then we all knew that, didn't we?

llvm-svn: 11255

llvm-svn: 11252

occurs in the program.

llvm-svn: 11249

placed into any alignment situation.

llvm-svn: 11247

in this for programs with lots of types (like the testcase in PR224).
The problem was that the type ID that the outer vector was using was not
very dense (as many types are getting resolved), so the vector is large
and gets reallocated a lot.

Since there are a lot of values in the program (the .ll file is 10M),
each reallocation has to copy the subvectors, which is also quite slow
(this wouldn't be a problem if C++ supported move semantics, but it
doesn't, at least not yet :(

Changing the outer data structure to a map speeds a release build of
llvm-as up from 11.21s to 5.13s on the testcase in PR224.

llvm-svn: 11244

llvm-svn: 11243

this speeds up a release llvm-as from 21.95s to 11.21s, because before it
would do an expensive traversal of the type-graph of every type resolved.

llvm-svn: 11242

type at the same time, resolve the upreferences to each other before resolving
it to the outer type.  This shaves off some time from the testcase in PR224, from
25.41s -> 21.72s.

llvm-svn: 11241

llvm-svn: 11239

instead of randomly groping about inside its outEdges array.
Make SchedGraph::addDummyEdges() use getNumOutEdges() instead of
outEdges.size().
Get rid of ifdefed-out code in SchedGraph::buildGraph().

llvm-svn: 11238

type resolution.  Unfortunately it doesn't help.

Also delete some dead debugging code.

llvm-svn: 11237

llvm-svn: 11233

consistent across the various type classes, we can factor out a LOT more
almost-identical code.  Also, add a couple of temporary statistics.

llvm-svn: 11232

all of the ad-hoc storage of contained types.  This allows getContainedType to
not be virtual, and allows us to entirely delete the TypeIterator class.

llvm-svn: 11230

llvm-svn: 11229

llvm-svn: 11228

llvm-svn: 11224

llvm-svn: 11222

contains the type we are looking for, just search the immediately used types.
We can only do this because we keep the "current" type in the nesting level
as we decrement upreferences.

This change speeds up the testcase in PR224 from 50.4s to 22.08s, not
too shabby.

llvm-svn: 11221

type from containing one.  This speeds up the asmparser on the testcase in PR224 from
61->50s.

llvm-svn: 11220

the Virt2PhysRegMap std::map with an std::vector.  This speeds up the
register allocator another (almost) 40%, from .72->.45s in a release build
of LLC on 253.perlbmk.

llvm-svn: 11219

llvm-svn: 11218

speeds up livevar from .48/.32s -> .45/.31s in LLC on perlbmk

llvm-svn: 11217

This speeds up live variables a lot, from .60/.39s -> .47/.26s in LLC, for
the first/second pass respectively.

llvm-svn: 11216

from physical registers, and they are always dense, it makes sense to not have
a ton of RBtree overhead.  This change speeds up regalloclocal about ~30% on
253.perlbmk, from .35s -> .27s in the JIT (in LLC, it goes from .74 -> .55).

Now live variable analysis is the slowest codegen pass.  Of course it doesn't
help that we have to run it twice, because regalloclocal doesn't update it,
but even if it did it would be the slowest pass (now it's just the 2x slowest
pass :(

llvm-svn: 11215

 1. The "work" was not in the assert, so it was punishing the optimized release
 2. getNamedFunction is _very_ expensive in large programs.  It is not designed
    to be used like this, and was taking 7% of the execution time of the code
    generator on perlbmk.

Since the assert "can never fail", I'm just killing it.

llvm-svn: 11214

strip it off.

llvm-svn: 11213

Have I ever mentioned how much I _hate_ constantpointerrefs?

llvm-svn: 11212

llvm-svn: 11210

even if it is wierd in some way.

llvm-svn: 11207

llvm-svn: 11206

llvm-svn: 11205

allow 'except' instead of 'unwind' here though.

llvm-svn: 11203

llvm-svn: 11202

llvm-svn: 11200

llvm-svn: 11199