| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Make Binary::TypeID more granular, to distinguish between ELF 32/64 little/big
llvm-svn: 152435
|
| |
|
|
|
|
|
| |
LLVM_READONLY.", getTypeInfo() is totally not READONLY, which I should have
probably noticed given that I made it so mere hours ago. Oops.
llvm-svn: 152434
|
| |
|
|
| |
llvm-svn: 152433
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an error made a record member invalid, the record would stay as "isBeingDefined" and
not "completeDefinition". Even easily recoverable errors ended up propagating records in
such "beingDefined" state, for example:
struct A {
~A() const; // expected-error {{'const' qualifier is not allowed on a destructor}}
};
struct B : A {}; // A & B would stay as "not complete definition" and "being defined".
This weird state was impending lookups in the records and hitting assertion in the ASTWriter.
Part of rdar://11007039
llvm-svn: 152432
|
| |
|
|
| |
llvm-svn: 152431
|
| |
|
|
| |
llvm-svn: 152430
|
| |
|
|
| |
llvm-svn: 152429
|
| |
|
|
|
|
| |
LLVM_READONLY.
llvm-svn: 152428
|
| |
|
|
|
|
|
|
|
| |
BEFORE the loader code has
winnowed all the unloaded libraries from the process module list.
<rdar://problem/11015223>
llvm-svn: 152427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The theory here is that we have these functions sprinkled in all over the
place. This should allow the optimizer to at least realize it can still do
load CSE across these calls.
- I blindly marked all instances as such, even though the optimizer can infer
this attribute in some instances (some of the inline ones) as that was easier
and also, when given the choice between thinking and not thinking, I prefer
the latter.
You might think this is mere frivolity, but actually this is good for a .7 -
1.1% speedup on 403.gcc/combine.c, JSC/Interpreter.cpp,
OGF/NSBezierPath-OAExtensions.m.
llvm-svn: 152426
|
| |
|
|
|
|
| |
to count the number of phis changed, not the number visited.
llvm-svn: 152425
|
| |
|
|
| |
llvm-svn: 152424
|
| |
|
|
|
|
| |
optimization to the whole Cocoa formatters infrastructure
llvm-svn: 152423
|
| |
|
|
|
|
| |
Previous code had a double free in MemoryBuffer. The tests now pass.
llvm-svn: 152422
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
to forward class, and assigning to an 'id' type var, message
sends default to 'id'. // rdar"//10988847
llvm-svn: 152420
|
| |
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
{CXXBaseSpecifier,Declarator,DeclSpec,TypeLoc,UnqualifiedId}::getLoc{Start,End}.
llvm-svn: 152418
|
| |
|
|
| |
llvm-svn: 152415
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
methods.
- 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
|
| |
|
|
|
|
| |
long).
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
|
| |
|
|
|
|
| |
not private.
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
|