int x(int t) {
  if (t & 256)
    return -26;
  return 0;
}

We generate this:

     tst.w   r0, #256
     mvn     r0, #25
     it      eq
     moveq   r0, #0

while gcc generates this:

     ands    r0, r0, #256
     it      ne
     mvnne   r0, #25
     bx      lr

Scandalous really!

During ISel time, we can look for this particular pattern. One where we have a
"MOVCC" that uses the flag off of a CMPZ that itself is comparing an AND
instruction to 0. Something like this (greatly simplified):

  %r0 = ISD::AND ...
  ARMISD::CMPZ %r0, 0         @ sets [CPSR]
  %r0 = ARMISD::MOVCC 0, -26  @ reads [CPSR]

All we have to do is convert the "ISD::AND" into an "ARM::ANDS" that sets [CPSR]
when it's zero. The zero value will all ready be in the %r0 register and we only
need to change it if the AND wasn't zero. Easy!

llvm-svn: 112664

llvm-svn: 112662

llvm-svn: 112661

llvm-svn: 112659

llvm-svn: 112657

llvm-svn: 112654

llvm-svn: 112653

llvm-svn: 112652

No CCR virtual registers should exist, and %EFLAGS is used in ways that can
surprise RegAllocFast.

llvm-svn: 112650

Reserved registers are unpredictable, and are treated as always live by machine
DCE.

Allocatable registers are never reserved, and can be used for virtual registers.

Unreserved, unallocatable registers can not be used for virtual registers, but
otherwise behave like a normal allocatable register. Most targets only have
the flag register in this set.

llvm-svn: 112649

llvm-svn: 112644

llvm-svn: 112643

llvm-svn: 112642

llvm-svn: 112638

llvm-svn: 112635

More cleanups of my JumpThreading transforms, including extracting some duplicated code into a helper function.

llvm-svn: 112634

llvm-svn: 112632

llvm-svn: 112631

llvm-svn: 112630

llvm-svn: 112628

llvm-svn: 112625

determining if they're likely to be in range of the SP when resolving
frame references.

llvm-svn: 112624

Remember byval argument's frame index during argument lowering and use this info to emit debug info.
Fixes Radar 8367011.

llvm-svn: 112623

the offset is legally encodable, not actually trying to do the encoding.

llvm-svn: 112622

llvm-svn: 112621

llvm-svn: 112620

llvm-svn: 112617

llvm-svn: 112615

llvm-svn: 112613

I have not been able to find a way to test each in isolation, for a few reasons:
1) The ability to look-through non-i1 BinaryOperator's requires the ability to look through non-constant
   ICmps in order for it to ever trigger.
2) The ability to do LVI-powered PHI value determination only matters in cases that ProcessBranchOnPHI
   can't handle.  Since it already handles all the cases without other instructions in the def-use chain
   between the PHI and the branch, it requires the ability to look through ICmps and/or BinaryOperators
   as well.

llvm-svn: 112611

llvm-svn: 112610

  1. Allocate them in the entry block of the function to enable function-wide
     re-use. The instructions to create them should be re-materializable, so
     there shouldn't be additional cost compared to creating them local
     to the basic blocks where they are used.
  2. Collect all of the frame index references for the function and sort them
     by the local offset referenced. Iterate over the sorted list to
     allocate the virtual base registers. This enables creation of base
     registers optimized for positive-offset access of frame references.
     (Note: This may be appropriate to later be a target hook to do the
     sorting in a target appropriate manner. For now it's done here for
     simplicity.)

llvm-svn: 112609

llvm-svn: 112608

llvm-svn: 112605

any more.  I plan to reimplement alloca promotion using SSAUpdater later.
It looks like Bill's URoR logic really always needs domtree, so the pass
now always asks for domtree info.

llvm-svn: 112597

two are weak, we make them thunks to a new strong function) so don't iterate
through the function list as we're modifying it.

Also add back the outermost loop which got removed during the cleanups.

llvm-svn: 112595

Don't perform an extra traversal of the function just to do cleanup.  We can safely simplify instructions after each block has been processed without worrying about iterator invalidation.

llvm-svn: 112594

- Convert {0,1} and friends into 0b01, which is identical and more consistent.

llvm-svn: 112593

llvm-svn: 112592

llvm-svn: 112591