eventually allow Passes to use profiling information to direct them.

llvm-svn: 11294

llvm-svn: 11293

llvm-svn: 11292

llvm-svn: 11288

methods which have strangely different semantics in different backends,
and noone knew what any did.

Getting rid of these ALSO allows the dependence of MachineInstr.h on
MRegisterInfo.h to be removed, which makes me much happier, and probably
alkis too.  :)

llvm-svn: 11287

llvm-svn: 11286

llvm-svn: 11285

llvm-svn: 11283

llvm-svn: 11282

llvm-svn: 11281

llvm-svn: 11280

MRegisterInfo::isPhysicalRegister(MO.getReg()) and the Sparc backend should
use isMachineRegister()

llvm-svn: 11279

llvm-svn: 11278

llvm-svn: 11277

llvm-svn: 11276

llvm-svn: 11275

llvm-svn: 11274

llvm-svn: 11273

programs use it instead of argc.

llvm-svn: 11270

* Doxygenified existing comments
* Compactified code to be more consistent

llvm-svn: 11268

llvm-svn: 11267

add a new -function argument
Add a new -o argument to specify where to put llvmprof.out data

llvm-svn: 11265

where to output the profiling data, if llvmprof.out is not good enough.

llvm-svn: 11264

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

llvm-svn: 11262

llvm-svn: 11261

llvm-svn: 11259

llvm-svn: 11257

llvm-svn: 11256

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: 11254

BUILD_SRC_ROOT != BUILD_OBJ_ROOT

llvm-svn: 11253

llvm-svn: 11252

as it fails.

llvm-svn: 11250

occurs in the program.

llvm-svn: 11249

random access iterators.

llvm-svn: 11248

placed into any alignment situation.

llvm-svn: 11247

Also, PR137 is a code quality PR, not a bug

llvm-svn: 11246

llvm-svn: 11245

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