llvm-svn: 123934

llvm-svn: 123933

llvm-svn: 123932

There should be no functional change from this, but I think it's simpler this
way.

llvm-svn: 123931

llvm-svn: 123833

Unfortunately, while this is the "right" thing to do, it breaks some ARM
asm parsing tests because MemMode5 and ThumbMemModeReg are ambiguous.  This
is tricky to resolve since neither is a subset of the other.

XFAIL the test for now.  The old way was broken in other ways, just ways
we didn't happen to be testing, and our ARM asm parsing is going to require
significant revisiting at a later point anyways.

llvm-svn: 123786

llvm-svn: 123770

llvm-svn: 123718

This is needed to allow an InstAlias for an instruction with an "OptionalDef"
result register (like ARM's cc_out) where you want to set the optional register
to reg0.

llvm-svn: 123490

the symbolic immediate names used for these instructions, fixing their pretty-printers, and
adding proper encoding information for them.

With this, we can properly pretty-print and encode assembly like:
	mrc p15, #0, r3, c13, c0, #3

Fixes <rdar://problem/8857858>.

llvm-svn: 123404

in the right direction. It eliminated some hacks and will unblock codegen
work. But it's far from being done. It doesn't reject illegal expressions,
e.g. (FOO - :lower16:BAR). It also doesn't work in Thumb2 mode at all.

llvm-svn: 123369

llvm-svn: 123174

This was suggested by Edmund Grimley Evans in pr8411.

llvm-svn: 123043

Rename lisp-like functions as suggested by Gabor Greif as loooong time
ago.  This is both easier to learn and easier to read.

llvm-svn: 123001

llvm-svn: 122542

llvm-svn: 122513

llvm-svn: 122509

llvm-svn: 122507

llvm-svn: 122506

new gcc warning that complains on self-assignments and
self-initializations.

llvm-svn: 122458

llvm-svn: 122337

something that just glues two nodes together, even if it is
sometimes used for flags.

llvm-svn: 122310

llvm-svn: 122015

llvm-svn: 121958

This isn't currently used for anything but I ran into it when experimenting
with some changes, and it might be useful in the future.

llvm-svn: 121911

This is still a WIP.  It's already good enough to expose a few bugs, though.

llvm-svn: 121868

Some quad-register intrinsics with lane operands only take a double-register
operand for the vector containing the lane.  The valid range of lane numbers
is then half as big as you would expect from the quad-register type.
Note: This currently has no effect because those intrinsics are now handled
entirely in the header file using __builtin_shufflevector, which does its own
range checking, but I want to use this for generating tests.

llvm-svn: 121867

llvm-svn: 121837

llvm-svn: 121822

registers that alias Reg, including itself. This is almost the same as the
existing getAliasSet() method, except for the inclusion of Reg.

The name matches the reflexive TRI::regsOverlap(x, y) relation.

It is very common to do stuff to a register and all its aliases:

  stuff(Reg)
  for (const unsigned *Alias = TRI->getAliasSet(Reg); *Alias; ++Alias)
    stuff(*Alias);

That can now be written as the simpler:

  for (const unsigned *Alias = TRI->getOverlaps(Reg); *Alias; ++Alias)
    stuff(*Alias);

This change requires a bit more constant space for the alias lists because Reg
is included and because the empty alias list cannot be shared any longer.

If the getAliasSet method is eventually removed, this space can be reclaimed by
sharing overlap lists. For instance, %rax and %eax have identical overlap sets.

llvm-svn: 121800

llvm-svn: 121798

instruction based on the t_addrmode_s# mode and what it returned. There is some
obvious badness to this. In particular, it's hard to do MC-encoding when the
instruction may change out from underneath you after the t_addrmode_s# variable
is finally resolved.

The solution is to revert a long-ago change that merged the reg/reg and reg/imm
versions. There is the addition of several new addressing modes. They no longer
have extraneous operands associated with them. I.e., if it's reg/reg we don't
have to have a dummy zero immediate tacked on to the SDNode.

There are some obvious cleanups here, which will happen shortly.

llvm-svn: 121747

Second attempt at make Thumb2 LEAs pseudos.  This time, perform the lowering much later, which makes the entire
process cleaner.

llvm-svn: 121735

Use the same COPY_TO_REGCLASS approach as for the 2-register *_sfp instructions.
This change made a big difference in the code generated for the
CodeGen/Thumb2/cross-rc-coalescing-2.ll test: The coalescer is still doing
a fine job, but some instructions that were previously moved outside the loop
are not moved now.  It's using fewer VFP registers now, which is generally
a good thing, so I think the estimates for register pressure changed and that
affected the LICM behavior.  Since that isn't obviously wrong, I've just
changed the test file.  This completes the work for Radar 8711675.

llvm-svn: 121730

llvm-svn: 121726

Make Thumb2 LEA-like instruction into pseudos, which map down to ADR.  Provide correct fixups for Thumb2 ADR,
which is _of course_ different from ARM ADR fixups, or any other Thumb2 fixup.

llvm-svn: 121721

In Thumb2, direct branches can be encoded as either a "short" conditional branch with a null predicate, or
as a "long" direct branch.  While the mnemonics are the same, they encode the branch offset differently, and
the Darwin assembler appears to prefer the "long" form for direct branches.  Thus, in the name of bitwise
equivalence, provide encoding and fixup support for it.

llvm-svn: 121710

  class A<bit a, bits<3> x, bits<3> y> {
    bits<3> z;
    let z = !if(a, x, y);
  }

The variable z will get the value of x when 'a' is 1 and 'y' when a is '0'.

llvm-svn: 121666

llvm-svn: 121661

llvm-svn: 121660