registers.

llvm-svn: 116961

when it means there is no specific clobber instruction.

llvm-svn: 116960

Attempt to fix valgrind complaining about (benign) leaks in pass registration by having PassRegistry
delete PassInfo objects that were created using new-style initialization.

llvm-svn: 116959

llvm-svn: 116958

llvm-svn: 116957

- Initial register pressure in the loop should be all the live defs into the
  loop. Not just those from loop preheader which is often empty.
- When an instruction is hoisted, update register pressure from loop preheader
  to the original BB.
- Treat only use of a virtual register as kill since the code is still SSA.

llvm-svn: 116956

llvm-svn: 116955

llvm-svn: 116954

llvm-svn: 116953

inclusion directives, keeping track of every #include, #import,
etc. in the translation unit. We keep track of the source location and
kind of the inclusion, how the file name was spelled, and the
underlying file to which the inclusion resolved.

llvm-svn: 116952

llvm-svn: 116951

llvm-svn: 116950

llvm-svn: 116949

llvm-svn: 116948

types are no longer Legal on X86, we don't need it.
No functional change.  8499854.

llvm-svn: 116947

llvm-svn: 116946

FunctionType!  I didn't realize it was available, until rjmccall
pointed out that DeclaratorDecl made the typeloc available.  This
makes FunctionDecl recursion *much* easier, because the typeloc can
take care of default parameters, so we no longer have to do that
separately, which means we can just do a normal type traversal instead
of this special-case WalkUp stuff we did before.

The only downside -- and it's minor -- is that because the TypeLoc
handles both the return type and the argument types, we can't recurse
on the explicit template args in the right place (which would be
between them).  I do it beforehand instead.  So for
   int MyFunc<float>(char x);
we get callbacks in the order: float, int, char.

Reviewed by chandlerc

llvm-svn: 116945

So the issue here was that we have lldb_private::FileSpec that by default was 
always resolving a path when using the:

FileSpec::FileSpec (const char *path);

and in the:

void FileSpec::SetFile(const char *pathname, bool resolve = true);

This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you 
type:

(lldb) breakpoint set --file file.c --line 5

If your current working directory is "/tmp", then "file.c" would be turned 
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.

So I removed the constructor that just takes a path:

FileSpec::FileSpec (const char *path); // REMOVED

You must now use the other constructor that has a "bool resolve" parameter that you must always supply:

FileSpec::FileSpec (const char *path, bool resolve);

I also removed the default parameter to SetFile():

void FileSpec::SetFile(const char *pathname, bool resolve);

And fixed all of the code to use the right settings.

llvm-svn: 116944

llvm-svn: 116943

llvm-svn: 116941

operand, also check if subregisters are killed.

Add <imp-def> operands for subregisters that remain alive after a super register
is killed.

I don't have a testcase for this that reproduces on trunk. <rdar://problem/8441758>

llvm-svn: 116940

parent call frame information.  And comment out the check for stop reason for the
time being.  The stop reason disappeared from the "thread backtrace" output for
breakpoint stop with condition.

llvm-svn: 116939

invocations of them into session object.

Remove a debug statement.

llvm-svn: 116938

llvm-svn: 116936

llvm-svn: 116932

Fix chained PCH issue; make sure all visible decls that will be put into a UPDATE_VISIBLE block were recorded beforehand.

llvm-svn: 116931

llvm-svn: 116930

to 'super'.

llvm-svn: 116928

llvm-svn: 116927

A recent commit to clang exposed a bug in the Win32 Path code. This is a
minimal fix for it.

llvm-svn: 116925

use it.

llvm-svn: 116920

#includes in the process.

llvm-svn: 116919

llvm-svn: 116918

As far as I can see, gcc is right to think this!  The following change
will cause a nice segfault rather than undefined behaviour if this case
occurs.  Someone who understands what this code is supposed to do should
probably take a proper look.

llvm-svn: 116917

say 'implicitly' when it was implicit.  Resolves PR 7930 and my peace of mind.

llvm-svn: 116916

llvm-svn: 116915

build bots.

llvm-svn: 116914

interactions with -isysroot and other driver commands.

llvm-svn: 116912

on a friend declaration, skip template-ids which do not depend on the
current parameter list.

llvm-svn: 116911

llvm-svn: 116910