Add a new LiveInterval::overlaps(). It checks if the live interval overlaps a range specified by [Start, End).

llvm-svn: 69434

into the wrong section (they shared the same lookup table).

llvm-svn: 69433

llvm-svn: 69432

llvm-svn: 69431

add some comments, change type from void* -> Stmt*, use
smallvector instead of vector.

llvm-svn: 69430

llvm-svn: 69429

llvm-svn: 69428

llvm-svn: 69427

llvm-svn: 69426

not "const void __builtin_prefetch(void *)".  This fixes PR3912.

llvm-svn: 69425

llvm-svn: 69424

llvm-svn: 69423

llvm-svn: 69422

AST context's __builtin_va_list type will be set when the PCH file is
loaded. This fixes the crash when CodeGen'ing a va_arg expression
pulled in from a PCH file.

llvm-svn: 69421

llvm-svn: 69417

llvm-svn: 69416

llvm-svn: 69415

way worked for me...

llvm-svn: 69414

llvm-svn: 69413

llvm-svn: 69412

Highlights: PP::isNextPPTokenLParen() no longer eats the ( 
when present.  We now simplify slightly the logic parsing
macro arguments.  We now handle PR3937 and other related cases
correctly.

llvm-svn: 69411

llvm-svn: 69410

for the optimization it's testing to kick in (although
it improves the code, getting rid of all spills).
I don't understand the optimization well enough to
rescue the test, so XFAILing.

llvm-svn: 69409

my earlier patch to this code only fixed half of it.

llvm-svn: 69408

"Hello, World!", this takes us from deserializing 6469
statements/expressions down to deserializing 1
statement/expression. It only translated into a 1% improvement on the
Carbon-prefixed 403.gcc, but (a) it's the right thing to do, and (b)
we expect this to matter more once we lazily deserialize identifiers.

llvm-svn: 69407

lazy PCH deserialization. Propagate that argument wherever it needs to
be. No functionality change, except that I've tightened up a few PCH
tests in preparation.

llvm-svn: 69406

llvm-svn: 69405

on the code.

llvm-svn: 69404

llvm-svn: 69403

llvm-svn: 69402

llvm-svn: 69401

llvm-svn: 69394

from a PCH file. It turns out that "Hello, World!" is bringing in 19%
of all of the statements in Carbon.h, so we need to be lazy.

llvm-svn: 69393

rdar://6800430

llvm-svn: 69392

1. We had logic in sema to decide whether or not to emit the error
   based on manually checking whether in a system header file.
2. we were allowing redefinitions of typedefs in class scope in C++
   if in header file.
3. there was no way to force typedef redefinitions to be accepted
   by the C compiler, which annoys me when stripping linemarkers out
   of .i files.

The fix is to split the C++ class typedef redefinition path from the
C path, and change the C path to be a warning that normally maps to
error.  This causes it to properly be ignored in system headers, 
etc. and gives us a way to control it.  Passing 
-Wtypedef-redefinition now turns the error into a warning.

One behavior change is that we now diagnose cases where you redefine
a typedef in your .c file that was defined in a header file.  This
seems like reasonable behavior, and the diagnostic now indicates that
it can be controlled with -Wtypedef-redefinition.

llvm-svn: 69391

  1) Accidentally used delete [] on an array of statements that was allocated with ASTContext's allocator
  2) Deserialization of names with multiple declarations (e.g., a struct and a function) used the wrong mangling constant, causing it to view declaration IDs as Decl*s.

403.gcc builds and links properly.

llvm-svn: 69390

llvm-svn: 69389

no-dead-strip set on them).

llvm-svn: 69388

llvm-svn: 69387

compiler to dump random stuff from the build into the file.  Right now this
amounts to dumping command line arguments and diagnostics to the file.

The idea is that you can set an envvar, do a world build of an OS, then grep 
through all the logs for interesting things or something.

Daniel, please wire the driver up to do something with this.

llvm-svn: 69386