ilist of MachineInstr objects. This allows constant time removal and
insertion of MachineInstr instances from anywhere in each
MachineBasicBlock. It also allows for constant time splicing of
MachineInstrs into or out of MachineBasicBlocks.

llvm-svn: 11340

llvm-svn: 11339

llvm-svn: 11335

llvm-svn: 11332

llvm-svn: 11331

actual profile info, and works!  :)

llvm-svn: 11324

llvm-svn: 11323

llvm-svn: 11322

llvm-svn: 11319

a profile tommorow.  :)

llvm-svn: 11318

llvm-svn: 11317

MO_VirtualRegister but if the register number is one of a physical
register is it considered as a physical register.

llvm-svn: 11315

llvm-svn: 11314

end of the function.

llvm-svn: 11313

more of a testcase for profiling information than anything that should reasonably
be used, but it's a starting point.  When I have more time I will whip this into
better shape.

llvm-svn: 11311

MO_VirtualRegister but actually be representing a physical register.

llvm-svn: 11310

llvm-svn: 11309

llvm-svn: 11308

Having a proper 'select' instruction would allow the elimination of a lot
of the special case cruft in this patch, but we don't have one yet.

llvm-svn: 11307

llvm-svn: 11305

llvm-svn: 11304

llvm-svn: 11302

llvm-svn: 11301

eventually allow Passes to use profiling information to direct them.

llvm-svn: 11294

llvm-svn: 11285

llvm-svn: 11283

llvm-svn: 11282

llvm-svn: 11281

llvm-svn: 11280

llvm-svn: 11278

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