when it was actually a Constant*.

There are quite a few other casts to Instruction that might have the same problem,
but this is the only one I have a test case for.

llvm-svn: 191668

llvm-svn: 191664

For some reason, adding definitions for these load and store
instructions changed whether some of the build bots matched
comparisons as signed or unsigned.

llvm-svn: 191663

llvm-svn: 191661

The only thing this does on its own is make the definitions of RISB[HL]G
a bit more precise.  Those instructions are only used by the MC layer at
the moment, so no behavioral change is intended.  The class is needed by
later patches though.

llvm-svn: 191660

Use subreg_hNN and subreg_lNN for the high and low NN bits of a register.
List the low registers first, so that subreg_l32 also means the low 32
bits of a 128-bit register.

Floats are stored in the upper 32 bits of a 64-bit register, so they
should use subreg_h32 rather than subreg_l32.

No behavioral change intended.

llvm-svn: 191659

It now points to the equivalent page on imgtec.com

llvm-svn: 191658

llvm-svn: 191656

I'm about to add support for high-word operations, so it seemed better
for the low-word registers to have names like R0L rather than R0W.
No behavioral change intended.

llvm-svn: 191655

Filter out repeated sections from the X86 disassembler modRMTable. Saves about ~43K from a released build. Unfortunately the disassembler tables are still upwards of 800K.

llvm-svn: 191652

Add a few more FMA4 disassembler test cases to match the scalar set with regards to combinations of L and W-bits.

llvm-svn: 191650

Add VEX_LIG to scalar FMA4 instructions.
Use VEX_LIG in some of the inheriting checks in disassembler table generator.
Make use of VEX_L_W, VEX_L_W_XS, VEX_L_W_XD contexts.
Don't let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from their non-L forms unless VEX_LIG is set.
Let VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE inherit from all of their non-L or non-W cases.
Increase ranking on VEX_L_W, VEX_L_W_XS, VEX_L_W_XD, VEX_L_W_OPSIZE so they get chosen over non-L/non-W forms.

llvm-svn: 191649

Those can occur in dead code. PR17402.

llvm-svn: 191644

llvm-svn: 191643

llvm-svn: 191638

llvm-svn: 191637

SDNode destructors are never called. As an optimization use AtomicSDNode's
internal storage if we have a small number of operands.

llvm-svn: 191636

llvm-svn: 191633

llvm-svn: 191632

llvm-svn: 191630

llvm-svn: 191628

out in projects. This appears to be working on my system, and I will be
watching build bots to see if there are any issues on other platforms.

llvm-svn: 191624

llvm-svn: 191611

llvm-svn: 191610

llvm-svn: 191604

We were completely ignoring the unorder/ordered attributes of condition
codes and also incorrectly lowering seto and setuo.

Reviewed-by: Vincent Lejeune<vljn at ovi.com>
llvm-svn: 191603

SelectionDAG will now attempt to inverse an illegal conditon in order to
find a legal one and if that doesn't work, it will attempt to swap the
operands using the inverted condition.

There are no new test cases for this, but a nubmer of the existing R600
tests hit this path.

llvm-svn: 191602

This is useful for targets like R600, which only support GT, GE, NE, and EQ
condition codes as it removes the need to handle unsupported condition
codes in target specific code.

There are no tests with this commit, but R600 has been updated to take
advantage of this new feature, so its existing selectcc tests are now
testing the swapped operands path.

llvm-svn: 191601

Interpreting the results of this function is not very intuitive, so I
cleaned it up to make it more clear whether or not a SETCC op was
legalized and how it was legalized (either by swapping LHS and RHS or
replacing with AND/OR).

This patch does change functionality in the LHS and RHS swapping case,
but unfortunately there are no in-tree tests for this.  However, this
patch is a prerequisite for R600 to take advantage of the LHS and RHS
swapping, so tests will be added in subsequent commits.

llvm-svn: 191600

llvm-svn: 191597

llvm-svn: 191595

We treat TBAA tags as struct-path aware TBAA format when the first operand
is a MDNode and the tag has 3 or more operands.

llvm-svn: 191593

of loops.

Previously, two consecutive calls to function "func" would result in the
following sequence of instructions:

1. load $16, %got(func)($gp) // load address of lazy-binding stub.
2. move $25, $16
3. jalr $25                  // jump to lazy-binding stub.
4. nop
5. move $25, $16
6. jalr $25                  // jump to lazy-binding stub again.

With this patch, the second call directly jumps to func's address, bypassing
the lazy-binding resolution routine:

1. load $25, %got(func)($gp) // load address of lazy-binding stub.
2. jalr $25                  // jump to lazy-binding stub.
3. nop
4. load $25, %got(func)($gp) // load resolved address of func.
5. jalr $25                  // directly jump to func.

llvm-svn: 191591

llvm-svn: 191585

llvm-svn: 191582

llvm-svn: 191579

resolved by lazy-binding.

llvm-svn: 191578

llvm-svn: 191576

llvm-svn: 191574

llvm-svn: 191571