llvm-svn: 70825

We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.

llvm-svn: 70824

hopefully, this fixes PR4144 without any regressions.

llvm-svn: 70823

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822

llvm-svn: 70821

  ThreadEdge directly.  This shares the code, but is just a refactoring.
* Make JumpThreading compute the set of loop headers and avoid threading
  across them.  This prevents jump threading from forming irreducible 
  loops (goodness) but also prevents it from threading in other cases that
  are beneficial (see the comment above FindFunctionBackedges).

llvm-svn: 70820

FindFunctionBackedges function.

llvm-svn: 70819

llvm-svn: 70818

llvm-svn: 70817

llvm-svn: 70816

The stack slots which share the same stack slot after coloring can, but do not have to, use the same register. In fact, they each may have different register class requirements.

llvm-svn: 70815

llvm-svn: 70814

llvm-svn: 70813

llvm-svn: 70812

llvm-svn: 70811

llvm-svn: 70810

llvm-svn: 70809

llvm-svn: 70808

 - The diagnostic is still poor, however. Doug, can you investigate?

 - Improved the test case to not depend on the file name, now it can
   be extended to actually check the formatting of the diagnostics
   (I'm hoping grep -A is portable here).

llvm-svn: 70807

stdint.h unless we are freestanding.

Any suggestions here are welcome.

llvm-svn: 70806

extension warning.

llvm-svn: 70805

llvm-svn: 70804

-Depend on DebugLocs for source line info.

llvm-svn: 70803

llvm-svn: 70800

llvm-svn: 70799

ivar layout.
 - The layout needs access to synthesized ivars.

llvm-svn: 70798

llvm-svn: 70797

llvm-svn: 70796

llvm-svn: 70795

llvm-svn: 70794

pasted token.

llvm-svn: 70793

llvm-svn: 70792

llvm-svn: 70791

is the empty set. :)  Thanks to Fritz for pointing this out.

llvm-svn: 70790

llvm-svn: 70789

throw exceptions.

llvm-svn: 70788

In some rare cases, the register allocator can spill registers but end up not utilizing registers at all. The fundamental problem is linearscan's backtracking can end up freeing more than one allocated registers. However,  reloads and restores might be folded into uses / defs and freed registers might not be used at all.

VirtRegMap keeps track of allocations so it knows what's not used. As a horrible hack, the stack coloring can color spill slots with *free* registers. That is, it replace reload and spills with copies from and to the free register. It unfold instructions that load and store the spill slot and replace them with register using variants.

Not yet enabled. This is part 1. More coming.

llvm-svn: 70787

llvm-svn: 70786

llvm-svn: 70785

in C++. Fixes <rdar://problem/6815995>.

llvm-svn: 70784