it needs to be mapped to refer to the function in the new module, not the old
one. Fixes PR7700.

llvm-svn: 109353

that a pointer can be null, forcing clients to think about it.

llvm-svn: 109348

llvm-svn: 109346

hanging off a value, then the dropping code will intentionally not drop
it too (since this is almost certainly a bug).

llvm-svn: 109337

instead of fixed size arrays, so that increasing FirstVirtualRegister to 16K
won't cause a compile time performance regression.

llvm-svn: 109330

Use current working directory when Dirname is empty. This only happens when absolute source file path is used on compiler command line.

llvm-svn: 109302

appropriate for targets without detailed instruction iterineries.
The scheduler schedules for increased instruction level parallelism in
low register pressure situation; it schedules to reduce register pressure
when the register pressure becomes high.

On x86_64, this is a win for all tests in CFP2000. It also sped up 256.bzip2
by 16%.

llvm-svn: 109300

llvm-svn: 109295

function live in set. This will give us tGPR for Thumb1 and GPR otherwise,
so the copy will be spillable. rdar://8224931

llvm-svn: 109293

to be of a different register class. For example, in Thumb1 if the live-in is
a high register, we want the vreg to be a low register. rdar://8224931

llvm-svn: 109291

suggested by Chris Lattner.

llvm-svn: 109290

llvm-svn: 109288

llvm-svn: 109285

comments explaining why it was wrong.  8225024.

Fix the real problem in 8213383: the code that splits very large
blocks when no other place to put constants can be found was not
considering the case that the block contained a Thumb tablejump.

llvm-svn: 109282

  it's too late to start backing off aggressive latency scheduling when most
  of the registers are in use so the threshold should be a bit tighter.
- Correctly handle live out's and extract_subreg etc.
- Enable register pressure aware scheduling by default for hybrid scheduler.
  For ARM, this is almost always a win on # of instructions. It's runtime
  neutral for most of the tests. But for some kernels with high register
  pressure it can be a huge win. e.g. 464.h264ref reduced number of spills by
  54 and sped up by 20%.

llvm-svn: 109279

llvm-svn: 109276

eliminate it.

llvm-svn: 109270

llvm-svn: 109269

the BlockTraits abstractions.

llvm-svn: 109268

llvm-svn: 109267

llvm-svn: 109266

llvm-svn: 109265

llvm-svn: 109262

llvm-svn: 109258

llvm-svn: 109248

are not demanded. This often allows the anyext to be folded away.

llvm-svn: 109242

llvm-svn: 109234

llvm-svn: 109224

I'll try to track down why a bit later.

llvm-svn: 109223

llvm-svn: 109222

llvm-svn: 109221

is not a good idea. The codebase does not depend
in this any more, and it may introduce hidden
runtime cost. If you get compile errors, please
dereference your iterator before passing to cast<>
(and friends).

Also: please consider caching the result of
operator* and reusing that instead of dereferencing
many times.

llvm-svn: 109220

llvm-svn: 109217

llvm-svn: 109216

llvmc can be now compiled with llvm-gcc on Windows.

llvm-svn: 109215

with an existing allocator.  The interesting use case of this
is that it allows "StringMap<whatever, BumpPtrAllocator&>" for
when you want to allocate out of a preexisting bump pointer
allocator owned by someone else.

llvm-svn: 109213

llvm-svn: 109212

llvm-svn: 109207

llvm-svn: 109206

llvm-svn: 109205