traversal, consider nodes for which the only successors are backedges
which the traversal is ignoring to be exit nodes. This fixes a problem
where the bottom-up traversal was failing to visit split blocks along
split loop backedges. This fixes rdar://10989035.
llvm-svn: 152421
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
- 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
~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
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
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
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
- 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
This solves an issue where a ValueObject was getting a wrong children count (usually, a huge value) and trying to resize the vector of children to fit that many ValueObject*
Added a loop detection algorithm to the synthetic children provider for std::list
Added a few more checks to the synthetic children provider for std::vector
Both std::list and std::vector's synthetic children providers now cache the count of children instead of recomputing it every time
std::map has a field that stores the count, so there is little need to cache it on our side
llvm-svn: 152371
caused several clients to select the slow variation. =[ This is extra
annoying because we don't have any realistic way of testing this -- by
design, these two functions *must* compute the same value.
Found while inspecting the output of some benchmarks I'm working on.
llvm-svn: 152369
Enrico Granata