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

Add complete assembler support for FMA3 instructions, with descriptions and encodings taken from the AVX manual

llvm-svn: 109204

SSE, so we can't return floating point values if this
is disabled.  Detect this error for clang.

With SSE1 only, f64 is a problem; it can be done, but
neither llvm-gcc nor clang has ever generated correct
code for it.  Since nobody noticed this I think it's
OK to treat it as an error for now.

This also handles SSE-sized vectors of floating point.
8207686, 8204109.

llvm-svn: 109201

Fix some AVX instructions which didnt had HasAVX prefix. And also a problem with PINSRW, which was totally wrong because of a typo I introduced previously

llvm-svn: 109198

llvm-svn: 109196

llvm-svn: 109174

llvm-svn: 109172