prefix.  Added a FIXME to remind us this still does not work when it is not the
first prefix.

llvm-svn: 152414

names.

llvm-svn: 152413

 - This cuts the # of getSourceRange calls by 60% on
   OGF/NSBezierPath-OAExtensions.m.

llvm-svn: 152412

 - getSourceRange() can be very expensive, we should try to avoid it if at all possible.

In conjunction with the previous commit I measured a ~2% speedup on 403.gcc/combine.c and a 3% speedup on OmniGroupFrameworks/NSBezierPath-OAExtensions.m.

llvm-svn: 152411

 - There are probably a lot more of these worth adding, but these are a start at hitting some of the exprs for which getSourceRange().getBegin() is a poor substitute for getLocStart().

llvm-svn: 152410

llvm-svn: 152409

more obvious.

llvm-svn: 152408

~0U might be i32 on 32-bit hosts, then (uint64_t)~0U might not be expected as (i64)0xFFFFFFFF_FFFFFFFF, but as (i64)0x00000000_FFFFFFFF.

llvm-svn: 152407

llvm-svn: 152406

negative switch cases if the branch condition is known to be positive.
Inspired by a recent improvement to GCC's VRP.

llvm-svn: 152405

llvm-svn: 152404

This renames the -Wformat-non-standard flag to -Wformat-non-iso,
rewords the current warnings a bit (pointing out that a format string
is not supported by ISO C rather than being "non standard"),
and adds a warning about positional arguments.

llvm-svn: 152403

llvm-svn: 152401

Patch by Tom Stellard!

llvm-svn: 152400

it to analyze extractvalue(llvm.[us](add|sub).with.overflow.*) intrinsics!

llvm-svn: 152398

This contains a semi-functional skeleton for the implementation of the
LLVM bindings for Python.

The API for the Object.h interface is roughly designed but not
implemented. MemoryBufferRef is implemented and actually appears to
work!

The ObjectFile unit test fails with a segmentation fault because the
LLVM library isn't being properly initialized. The build system doesn't
know about this code yet, so no alerts should fire.

llvm-svn: 152397

llvm-svn: 152396

llvm-svn: 152395

llvm-svn: 152394

llvm-svn: 152393

and lots of tidying up.

llvm-svn: 152392

llvm-svn: 152391

llvm-svn: 152390

llvm-svn: 152389

llvm-svn: 152388

llvm-svn: 152387

llvm-svn: 152386

llvm-svn: 152384

llvm-svn: 152383

llvm-svn: 152382

Get function boundaries from the LC_FUNCTION_STARTS load command. This helps to determine symbol sizes and also allows us to be able to debug stripped binaries.

If you have a stack backtrace that goes through a function that has been stripped from the symbol table, the variables for any functions above that stack frame will most likely be incorrect. It can also affect our ability to step in/out/through of a function.

llvm-svn: 152381

Don't show variable values in Xcode when they are out of scope. This allows Xcode to step a lot faster when there are many variables in the variables view.

llvm-svn: 152380

llvm-svn: 152379

llvm-svn: 152378

 - On -emit-llvm-only of 403.gcc/combine.c, for example, we make 160k calls to
   getTypeInfo but only ever deal with 680 some distinct types.

I saw these speedups (user time):
  403.gcc/combine.c -- 3.1%
  OmniGroupFrameworks/NSBezierPath-OAExtensions.m -- 3.6%
  JavaScriptCore/Interpreter.cpp -- 1.4%
which seems pretty sweet.

I ran some histograms on those compiles and we end up doing a ton of
getTypeInfo() on 'char' and 'int'. I tried splitting out a fast path for builtin
types, but this wasn't a win. Still kinda seems like we could be doing better
here.

llvm-svn: 152377

<rdar://problem/10975912>

llvm-svn: 152376

type-analysis;  otherwise, we just completely do the
wrong thing for placeholders.

llvm-svn: 152375

llvm-svn: 152374

llvm-svn: 152373

Make sure we update the static local decl address map when we are forced to rebuild a global because of the initializer.  <rdar://problem/10957867>.

llvm-svn: 152372