llvm-svn: 98932

match.  Jakob, please take a look when you get a chance.

llvm-svn: 98931

can't match or just have no testcases.  Will remove after 
confirmation from dan that they really are dead.

llvm-svn: 98930

llvm-svn: 98928

llvm-svn: 98919

to input patterns, we can fix X86ISD::CMP and X86ISD::BT as taking
two inputs (which have to be the same type) and *returning an i32*.
This is how the SDNodes get made in the graph, but we weren't able
to model it this way due to deficiencies in the pattern language.

Now we can change things like this:

 def UCOM_FpIr80: FpI_<(outs), (ins RFP80:$lhs, RFP80:$rhs), CompareFP,
-                  [(X86cmp RFP80:$lhs, RFP80:$rhs),
-                   (implicit EFLAGS)]>; // CC = ST(0) cmp ST(i)
+                  [(set EFLAGS, (X86cmp RFP80:$lhs, RFP80:$rhs))]>;

and fix terrible crimes like this:

-def : Pat<(parallel (X86cmp GR8:$src1, 0), (implicit EFLAGS)),
+def : Pat<(X86cmp GR8:$src1, 0),
           (TEST8rr GR8:$src1, GR8:$src1)>;

This relies on matching the result of TEST8rr (which is EFLAGS, which is
an implicit def) to the result of X86cmp, an i32.

llvm-svn: 98903

llvm-svn: 98902

llvm-svn: 98901

llvm-svn: 98889

llvm-svn: 98888

Refactor Reg-Reg copy emission routine for ARM. This makes cross-regclass copies weirdness more straightforward. Also, add GPR <-> SPR copy support.

llvm-svn: 98887

llvm-svn: 98881

were missing it on some movq instructions and were not including the appropriate
PCrel bias.

llvm-svn: 98880

llvm-svn: 98869

llvm-svn: 98866

llvm-svn: 98864

llvm-svn: 98862

No functional changes.

llvm-svn: 98860

temporary workaround for matching inc/dec on x86_64 to the correct instruction.
 - This hack will eventually be replaced with a robust mechanism for handling
   matching instructions based on the available target features.

llvm-svn: 98858

llvm-svn: 98855

files that produce special relocation types where the 
linker changes movq's into lea's.

llvm-svn: 98839

llvm-svn: 98835

intrinsics.  The intrinsic lookup code assumes that this check has been done
and assumes the names are at least 6 characters long.  Valgrind complained
about this.  pr6638.

llvm-svn: 98831

llvm-svn: 98819

llvm-svn: 98810

MC/Darwin: Add a new target hook for whether the target uses "reliable" symbol differences, basically whether the assembler should attempt to understand atoms when using scattered symbols.

Also, avoid some virtual call overhead.

llvm-svn: 98789

X86 address mode matching code MatchAddressRecursively does some aggressive hack which require doing a RAUW. It may end up deleting some SDNode up stream. It should avoid referencing deleted nodes.

llvm-svn: 98780

There is a better way coming up.

llvm-svn: 98777

matches that of Firstcond[0] and E means otherwise.  The Firstcond[0] is also
tagged in the Mask to facilitate Asm printing.  The disassembler also depends
on this arrangement.  This is similar to what's described in A2.5.2 ITSTATE.

Ran:

utils/lit/lit.py test/CodeGen/ARM test/CodeGen/Thumb test/CodeGen/Thumb2

successfully.

llvm-svn: 98775

addressing modes to omit the '+' from the assembler syntax #+/-<imm> or +/-<Rm>.

This patch removes the impl of printT2AddrModeImm8s4OffsetOperand() from
ARMAsmPrinter.cpp.  It is used by disassembler as of now.

llvm-svn: 98774

llvm-svn: 98769

in svn r74988 but the format field was never widened.

llvm-svn: 98768

llvm-svn: 98763

Remove it from ARMAddressingModes.h.

llvm-svn: 98751

instructions to help disassembly.

We also changed the output of the addressing modes to omit the '+' from the
assembler syntax #+/-<imm> or +/-<Rm>.  See, for example, A8.6.57/58/60.

And modified test cases to not expect '+' in +reg or #+num.  For example,

; CHECK:       ldr.w	r9, [r7, #28]

llvm-svn: 98745

should use CreateTempSymbol() if they don't care about the
name.

llvm-svn: 98712

llvm-svn: 98692

optional register update argument, which is currently unused -- when we add
support for that, it can just be a separate operand.

llvm-svn: 98683

handling constant unions.

llvm-svn: 98680

This is for the disassembly work.

There are cases where this is not possible, for example, A8.6.53 LDM Encoding T1.
In such case, we'll use an adhoc approach to deduce the Opcode programmatically.

llvm-svn: 98679