- Apr 12, 2013
-
-
Benjamin Kramer authored
Fix a disconcerting bug in Value::isUsedInBasicBlock, which gave wrong answers for blocks larger than 3 instrs. Also add a unit test. PR15727. llvm-svn: 179370
-
Alexey Samsonov authored
llvm-svn: 179368
-
Alexey Samsonov authored
llvm-svn: 179367
-
Alexey Samsonov authored
llvm-svn: 179366
-
Alexey Samsonov authored
llvm-svn: 179365
-
Nico Rieck authored
llvm-svn: 179364
-
Nico Rieck authored
llvm-svn: 179363
-
Nico Rieck authored
llvm-svn: 179362
-
Nico Rieck authored
llvm-svn: 179361
-
Nico Rieck authored
This test ensures that relocation type names returned by libObject match the raw relocation type value. llvm-svn: 179360
-
Nico Rieck authored
This option expands shown relocations from single line to a dictionary format: Relocation { Offset: 0x4 Type: R_386_32 (1) Symbol: sym Info: 0x0 } llvm-svn: 179359
-
Nico Rieck authored
llvm-svn: 179358
-
Nico Rieck authored
MIPS64EL relocation entries have up to three relocation operations. Because libObject only exposes a single relocation name, use the concatenation of the individual relocation type names. llvm-svn: 179357
-
Hal Finkel authored
This is prep. work for the implementation of optimizeCompare. Many PPC instructions have 'record' forms (in almost all cases, this means that the RC bit is set) that cause the result of the instruction to be compared with zero, and the result of that comparison saved in a predefined condition register. In order to add the record forms of the instructions without too much copy-and-paste, the relevant functions have been refactored into multiclasses which define both the record and normal forms. Also, two TableGen-generated mapping functions have been added which allow querying the instruction code for the record form given the normal form (and vice versa). No functionality change intended. llvm-svn: 179356
-
Nadav Rotem authored
llvm-svn: 179355
-
Nadav Rotem authored
llvm-svn: 179354
-
Nadav Rotem authored
When debugging performance regressions we often ask ourselves if the regression that we see is due to poor isel/sched/ra or due to some micro-architetural problem. When comparing two code sequences one good way to rule out front-end bottlenecks (and other the issues) is to force code alignment. This pass adds a flag that forces the alignment of all of the basic blocks in the program. llvm-svn: 179353
-
Jordan Rose authored
By Adam Schnitzer! llvm-svn: 179352
-
Jordan Rose authored
Before: 1. Calling 'foo' 2. Doing something interesting 3. Returning from 'foo' 4. Some kind of error here After: 1. Calling 'foo' 2. Doing something interesting 3. Returning from 'foo' 4. Some kind of error here The location of the note is already in the caller, not the callee, so this just brings the "depth" attribute in line with that. This only affects plist diagnostic consumers (i.e. Xcode). It's necessary for Xcode to associate the control flow arrows with the right stack frame. <rdar://problem/13634363> llvm-svn: 179351
-
Jordan Rose authored
In this code int getZero() { return 0; } void test() { int problem = 1 / getZero(); // expected-warning {{Division by zero}} } we generate these arrows: +-----------------+ | v int problem = 1 / getZero(); ^ | +---+ where the top one represents the control flow up to the first call, and the bottom one represents the flow to the division.* It turns out, however, that we were generating the top arrow twice, as if attempting to "set up context" after we had already returned from the call. This resulted in poor highlighting in Xcode. * Arguably the best location for the division is the '/', but that's a different problem. <rdar://problem/13326040> llvm-svn: 179350
-
Rafael Espindola authored
llvm-svn: 179349
-
Jason Molenda authored
settings set platform.plugin.darwin-kernel.search-locally-for-kexts true llvm-svn: 179348
-
Douglas Gregor authored
llvm-svn: 179347
-
rdar://problem/13615607Douglas Gregor authored
This is a Darwin-SDK-specific hash criteria used to identify a particular SDK without having to hash the contents of all of its headers. If other platforms have such versioned files, we should add those checks here. llvm-svn: 179346
-
Rafael Espindola authored
Original message: Print more information about relocations. With this patch llvm-readobj now prints if a relocation is pcrel, its length, if it is extern and if it is scattered. It also refactors the code a bit to use bit fields instead of shifts and masks all over the place. llvm-svn: 179345
-
Chad Rosier authored
llvm-svn: 179344
-
Chad Rosier authored
variables that use namespace alias qualifiers. Test case coming on clang side shortly. Part of rdar://13499009 llvm-svn: 179343
-
Enrico Granata authored
When -T is specified, the test suite will call svn info and dump the output on screen (this used to be the default behavior) When -T is not specified, this step won't be performed (the new default) llvm-svn: 179342
-
Enrico Granata authored
When specifying a relative path for the --framework option to dotest.py, Python would end up being confused and unable to locate the embedded_interpreter module, causing every testcase that uses the Script Interpreter (e.g. functionalities/data-formatter/data-formatter-stl/libstdcpp) to fail without even trying This checkin fixes that problem by absolutizing the path before pushing it to the sys.path llvm-svn: 179341
-
Chad Rosier authored
llvm-svn: 179340
-
Chad Rosier authored
namespace alias qualifiers. Test case coming on clang side shortly. Part of rdar://13499009 llvm-svn: 179339
-
John McCall authored
llvm-svn: 179338
-
Manman Ren authored
Added PathAliases to check if two struct-path tags can alias. Added command line option -struct-path-tbaa. llvm-svn: 179337
-
Chad Rosier authored
can build up the identifier string. No test case as support for looking up these type of identifiers hasn't been implemented on the clang side. Part of rdar://13499009 llvm-svn: 179336
-
Manman Ren authored
For struct-path aware TBAA, we used to use scalar type node as the scalar tag, which has an incompatible format with the struct path tag. We now use the same format: base type, access type and offset. We also uniformize the scalar type node and the struct type node: name, a list of pairs (offset + pointer to MDNode). For scalar type, we have a single pair. These are to make implementaiton of aliasing rules easier. llvm-svn: 179335
-
John McCall authored
Patch by John Marino. llvm-svn: 179334
-
rdar://problem/13558484Enrico Granata authored
This makes the dynamic values test case work for both libc++ and libstdcpp llvm-svn: 179333
-
Jim Ingham authored
Save away the locations at the site we hit and iterate over that collection. Otherwise the action of one location could delete the other locations, and that would leave us iterating over a reduced size collection and crash. <rdar://problem/13592544> llvm-svn: 179332
-
Manman Ren authored
llvm-svn: 179331
-
rdar://problem/13623698Enrico Granata authored
This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
-