llvm-svn: 60632

llvm-svn: 60631

type mimatches.

llvm-svn: 60630

llvm-svn: 60629

llvm-svn: 60628

llvm-svn: 60627

llvm-svn: 60626

testing declaration of properties in categories.

llvm-svn: 60625

llvm-svn: 60624

llvm-svn: 60623

llvm-svn: 60622

llvm-svn: 60621

attributes. Example would be, readonly, assign or
assign, copy, etc.

llvm-svn: 60620

doesn't do its own local caching, and is slightly more aggressive about
free/store dse (see testcase).  This eliminates the last external client 
of MemDep::getDependenceFrom().

llvm-svn: 60619

  template<typename T> void f(T x) {
    g(x); // g is a dependent name, so don't even bother to look it up
    g(); // error: g is not a dependent name
  }

Note that when we see "g(", we build a CXXDependentNameExpr. However,
if none of the call arguments are type-dependent, we will force the
resolution of the name "g" and replace the CXXDependentNameExpr with
its result.

GCC actually produces a nice error message when you make this
mistake, and even offers to compile your code with -fpermissive. I'll
do the former next, but I don't plan to do the latter.

llvm-svn: 60618

since %p isn't formatted consistently, but obviously plain %x is wrong.
PRIxPTR with a cast to uintptr_t would work here, but that requires
inconvenient build-system changes. %lu works on all current and
foreseable future hosts.

llvm-svn: 60616

expressions, and value-dependent expressions. This permits us to parse
some template definitions.

This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.

llvm-svn: 60615

llvm-svn: 60614

llvm-svn: 60611

property. It also checks for duplicate use of the same ivar
in two different iproperty implementations. It also caught
an error for a test case used in CodeGen :).

llvm-svn: 60610

llvm-svn: 60609

loops when they can be subsumed into addressing modes.

Change X86 addressing mode check to realize that
some PIC references need an extra register.
(I believe this is correct for Linux, if not, I'm sure
someone will tell me.)

llvm-svn: 60608

1. Merge the 'None' result into 'Normal', making loads
   and stores return their dependencies on allocations as Normal.
2. Split the 'Normal' result into 'Clobber' and 'Def' to
   distinguish between the cases when memdep knows the value is
   produced from when we just know if may be changed.
3. Move some of the logic for determining whether readonly calls
   are CSEs into memdep instead of it being in GVN.  This still
   leaves verification that the arguments are hte same to GVN to
   let it know about value equivalences in different contexts.
4. Change memdep's call/call dependency analysis to use 
   getModRefInfo(CallSite,CallSite) instead of doing something 
   very weak.  This only really matters for things like DSA, but
   someday maybe we'll have some other decent context sensitive
   analyses :)
5. This reimplements the guts of memdep to handle the new results.
6. This simplifies GVN significantly:
   a) readonly call CSE is slightly simpler
   b) I eliminated the "getDependencyFrom" chaining for load 
      elimination and load CSE doesn't have to worry about 
      volatile (they are always clobbers) anymore.
   c) GVN no longer does any 'lastLoad' caching, leaving it to 
      memdep.
7. The logic in DSE is simplified a bit and sped up.  A potentially
   unsafe case was eliminated.

llvm-svn: 60607

Wesley Peck, with a few fixes by me.

llvm-svn: 60605

See PR3160 for details

llvm-svn: 60604

llvm-svn: 60601

like binary operators.

llvm-svn: 60600

type mismatch (related to my last patch).

llvm-svn: 60599

(instance/class) Method type checking between category and its implementation.
And a test case for all.

llvm-svn: 60598

parameters, with some semantic analysis:
  - Template parameters are introduced into template parameter scope
  - Complain about template parameter shadowing (except in Microsoft mode)

Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates. 

Next up: dependent types and value-dependent/type-dependent
expressions.

llvm-svn: 60597

Reason #3 from 60595 doesn't hold true. If we can fold a PIC load from constpool into a use, the rewrite happens at time of spill (not in VirtRegMap). Later on, if the GlobalBaseReg is spilled, the spiller can see the use uses GlobalBaseReg and do the right thing.

llvm-svn: 60596

Effectively undo 60461 in PIC mode which simply transform V_SET0 / V_SETALLONES into a load from constpool in order to fold into restores. This is not safe to do when PIC base is being used for a number of reasons:
1. GlobalBaseReg may have been spilled.
2. It may not be live at the use.
3. Spiller doesn't know this is happening so it won't prevent GlobalBaseReg from being spilled later (That by itself is a nasty hack. It's needed because we don't insert the reload until later).

llvm-svn: 60595

llvm-svn: 60594

llvm-svn: 60593

llvm-svn: 60592

llvm-svn: 60591

  for(Type1 B = ...;;) { Type2 B ; ... }
is bad: code is hard to read and VS VS don't like it (it ignore the second declaration of B).
This patch fix the problem in tablegen. Please don't write code like this. 

llvm-svn: 60590

llvm-svn: 60588

heretical from a STL standpoint, but is oh-so-useful for things that 
can't throw exceptions when copied, like, well, everything in LLVM.

llvm-svn: 60587

llvm-svn: 60586