llvm-svn: 110248

llvm-svn: 110244

be triggered by valid, if dubious, IR.

llvm-svn: 110240

While spilling live registers at the end of block check whether they are used by DBG_VALUE machine instructions or not. If a spilled register is used by DBG_VALUE machine instruction then insert a new DBG_VALUE machine instruction to encode variable's new location on stack.

llvm-svn: 110235

llvm-svn: 110234

llvm-svn: 110183

When the normalizeSpillWeights function was introduced, I forgot to remove this
normalization.

This change could affect register allocation. Hopefully for the better.

llvm-svn: 110119

llvm-svn: 110069

llvm-svn: 110045

Fixes potential ambiguity problems on VS 2010.

Patch by nobled!

llvm-svn: 110029

ISD::AND case of TargetLowering::SimplifyDemandedBits.

llvm-svn: 110019

llvm-svn: 109966

check the range of the constant when optimizing a comparison between a
constant and a sign_extend_inreg node.

llvm-svn: 109854

Plug the remaining MC leaks by giving MCObjectStreamer/MCAsmStreamer ownership of the TargetAsmBackend and the MCCodeEmitter.

llvm-svn: 109767

llvm-svn: 109765

multiple defs, like t2LDRSB_POST.

The first def could accidentally steal the physreg that the second, tied def was
required to be allocated to.

Now, the tied use-def is treated more like an early clobber, and the physreg is
reserved before allocating the other defs.

This would never be a problem when the tied def was the only def which is the
usual case.

This fixes MallocBench/gs for thumb2 -O0.

llvm-svn: 109715

llvm-svn: 109608

llvm-svn: 109538

llvm-svn: 109525

recursively and returning a SCALAR_TO_VECTOR node, but assuming the input was always a BUILD_VECTOR.

llvm-svn: 109519

llvm-svn: 109513

llvm-svn: 109511

protectors, to be near the stack protectors on the stack. Accomplish this by
tagging the stack object with a predicate that indicates that it would trigger
this. In the prolog-epilog inserter, assign these objects to the stack after the
stack protector but before the other objects.

llvm-svn: 109481

rewrite instructions for live range splitting.

Still work in progress.

llvm-svn: 109469

llvm-svn: 109468

llvm-svn: 109462

The "excess register pressure" returned by HighRegPressure() is not accurate enough to factor into scheduling priority. Eliminate it and add early exits to speed up scheduling.

llvm-svn: 109449

llvm-svn: 109415

llvm-svn: 109402

may be used uninitialized in the callers of HighRegPressure.

llvm-svn: 109393

llvm-svn: 109388

llvm-svn: 109383

those.  Radar 8231572.

llvm-svn: 109367

llvm-svn: 109354

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

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

llvm-svn: 109285

  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