llvm-svn: 153599

Branch folding invalidates liveness and disables liveness verification
on some targets.

llvm-svn: 153597

Extract the liveness verification into its own method.

This makes it possible to run the machine code verifier after liveness
information is no longer required to be valid.

llvm-svn: 153596

This avoids the silly double search:

  if (isLiveIn(Reg))
    removeLiveIn(Reg);

llvm-svn: 153592

llvm-svn: 153579

llvm-svn: 153571

and not the rest of the member tag.

Fixes PR11695

llvm-svn: 153570

will always be tiny sets, so DenseSet is overkill (SmallSet won't work as we
need iteration support). 

llvm-svn: 153529

Fixes PR10105

llvm-svn: 153524

llvm-svn: 153518

Branch folding can use a register scavenger to update liveness
information when required. Don't do that if liveness information is
already invalid.

llvm-svn: 153517

llvm-svn: 153513

Late optimization passes like branch folding and tail duplication can
transform the machine code in a way that makes it expensive to keep the
register liveness information up to date. There is a fuzzy line between
register allocation and late scheduling where the liveness information
degrades.

The MRI::tracksLiveness() flag makes the line clear: While true,
liveness information is accurate, and can be used for register
scavenging. Once the flag is false, liveness information is not
accurate, and can only be used as a hint.

Late passes generally don't need the liveness information, but they will
sometimes use the register scavenger to help update it. The scavenger
enforces strict correctness, and we have to spend a lot of code to
update register liveness that may never be used.

llvm-svn: 153511

register that's read by the preheader terminator.

rdar://11095580

llvm-svn: 153492

copies being considered for removal. Make sure to track all of the copies,
rather than just the most recent encountered, by holding a DenseSet instead of
an unsigned in SrcMap.

No test case - couldn't reduce something with a sane size.

llvm-svn: 153487

llvm-svn: 153483

backtrace locations.

Testcase forthcoming, but I wanted to get some testing here.

Should fix:

PR12323
PR12314
rdar://11091100

llvm-svn: 153471

llvm-svn: 153438

llvm-svn: 153429

llvm-svn: 153428

llvm-svn: 153372

Dump the hex representation to the comment stream as well as the float
value.

llvm-svn: 153346

llvm-svn: 153341

llvm-svn: 153270

llvm-svn: 153269

metadata operand as an actual operand, leading to an assert. Error
out in this case.

rdar://11007633

llvm-svn: 153234

execution-time regression for nsieve-bits on the ARMv7 -O0 -g nightly tester.
This may also improve compile-time on architectures that would otherwise 
generate a libcall for urem (e.g., ARM) or fall back to the DAG selector.
rdar://10810716

llvm-svn: 153230

Type legalization can zero-extend the elements of the build_vector node, so,
for example, we may have an <8 x i8> with i32 elements of value 255. That
should return 'true' for the vector being all ones.

llvm-svn: 153203

llvm-svn: 153162

llvm-svn: 153161

llvm-svn: 153160

llvm-svn: 153159

llvm-svn: 153158

i128). In that case, we may not be able to print out the MCExpr as an
expression. For instance, we could have an MCExpr like this:

    0xBEEF0000BEEF0000 | (0xBEEF0000BEEF0000 << 64)

The MCExpr printer handles sizes up to 64-bits, but this expression would
require 128-bits. In this situation, try to evaluate the constant expression and
emit that as the value into 64-bit chunks.
<rdar://problem/11070338>

llvm-svn: 153081

When combining (vextract shuffle (load ), <1,u,u,u>), 0) -> (load ), add users of the final load to the worklist too. Needed by changes I'm preparing to make to X86 backend.

llvm-svn: 153078

a variable. The previous code would break the debug info changing
code invariant. This will regress debug info for arguments where
we elide the alloca created.

Fixes rdar://11066468

llvm-svn: 153074

llvm-svn: 153073

llvm-svn: 153072

llvm-svn: 153071

llvm-svn: 153064