The complement interval may overlap the other intervals created, so use
a separate LiveRangeCalc instance to compute its live range.

A LiveRangeCalc instance can only be shared among non-overlapping
intervals.

llvm-svn: 139603

llvm-svn: 139601

llvm-svn: 139598

Only disassembler instructions with vvvv != 1111 if the instruction actually uses the vvvv field to encode an operand. Fixes PR10851.

llvm-svn: 139591

Remove filter that was preventing MOVDQU/MOVDQA and their VEX forms from being disassembled. Also added encodings for the other register/register form of these instructions. Fixes PR10848.

llvm-svn: 139588

Fix encoding of VMOVDQU to not simultaneously be 'TB OpSize' and 'XS'. 'XS' is correct and seems to have been taking priority.

llvm-svn: 139587

llvm-svn: 139583

llvm-svn: 139581

llvm-svn: 139579

llvm-svn: 139578

llvm-svn: 139577

llvm-svn: 139576

llvm-svn: 139575

llvm-svn: 139574

llvm-svn: 139573

SplitKit will soon need two copies of these data structures, and the
algorithms will also be useful when LiveIntervalAnalysis becomes
independent of LiveVariables.

llvm-svn: 139572

llvm-svn: 139571

llvm-svn: 139565

Fix the assembler strings for a couple of atomic instructions.  Doesn't really matter much in practice, but it's a bit cleaner.

llvm-svn: 139563

llvm-svn: 139559

which is only relevant with canonical IVs

llvm-svn: 139556

llvm-svn: 139554

destination types are equal!

llvm-svn: 139553

Otherwise this case is now covered by no-iv-rewrite.ll.

llvm-svn: 139552

Fix a failing ELF Thumb test.  I _think_ this is right, but it's not totally clear to me what this test is doing.  Could someone on an ELF platform check?

llvm-svn: 139549

Splitting a landing pad takes considerable care because of PHIs and other
nasties. The problem is that the jump table needs to jump to the landing pad
block. However, the landing pad block can be jumped to only by an invoke
instruction. So we clone the landingpad instruction into its own basic block,
have the invoke jump to there. The landingpad instruction's basic block's
successor is now the target for the jump table.

But because of PHI nodes, we need to create another basic block for the jump
table to jump to. This is definitely a hack, because the values for the PHI
nodes may not be defined on the edge from the jump table. But that's okay,
because the jump table is simply a construct to mimic what is happening in the
CFG. So the values are mysteriously there, even though there is no value for the
PHI from the jump table's edge (hence calling this a hack).

llvm-svn: 139545

llvm-svn: 139544

llvm-svn: 139542

llvm-svn: 139541

llvm-svn: 139537

which is relevant with canonical IVs. Anything else being checked by
these tests is already covered by early CSE.

llvm-svn: 139535

No tests; these changes aren't really interesting in the sense that the logic is the same for volatile and atomic.

I believe this completes all of the changes necessary for the optimizer to handle loads and stores correctly.  I'm going to try and come up with some additional testing, though.

llvm-svn: 139533

There's no need to add additional predicate operands when converting a tB to a tBfar now.  Fixes nightly test failures on armv6 Thumb.  <rdar://problem/10110404>

llvm-svn: 139531

llvm-svn: 139530

However with this fix it does now.

Basically the operand order for the x86 target specific node
is not the same as the instruction, but since the intrinsic need that
specific order at the instruction definition, just change the order
during legalization. Also, there were some wrong invertions of condition
codes, such as GE => LE, GT => LT, fix that too. Fix PR10907.

llvm-svn: 139528

llvm-svn: 139527

llvm-svn: 139526

llvm-svn: 139525

Port more encoding tests to decoding tests, and correct an improper Thumb2 pre-indexed load decoding this uncovered.

llvm-svn: 139522

llvm-svn: 139518