| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 136754
|
| |
|
|
|
|
|
| |
function, be sure to drop parameter attributes when dropping their
associated arguments. Patch by Aaron Landwehr!
llvm-svn: 136753
|
| |
|
|
|
|
|
|
|
| |
Don't replace a gep/bitcast with 'undef' because that will form a "free(undef)"
which in turn means "unreachable". What we wanted was a no-op. Instead, analyze
the whole tree and look for all the instructions we need to delete first, then
delete them second, not relying on the use_list to stay consistent.
llvm-svn: 136752
|
| |
|
|
|
|
| |
the function, because the UnwindInst is going away.
llvm-svn: 136751
|
| |
|
|
|
|
| |
Signed-off-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 136750
|
| |
|
|
|
| |
Signed-off-by: Tobias Grosser <tobias@grosser.es>
llvm-svn: 136749
|
| |
|
|
|
|
|
|
|
|
|
| |
1. Be more tolerant of comments in -CC (comment-preserving) mode. We were missing a few cases.
2. Make sure to expand the second FOO in "#if defined FOO FOO". (See also
r97253, which addressed the case of "#if defined(FOO FOO".)
Fixes PR10286.
llvm-svn: 136748
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
was previously using the entire frame variable list instead of using the
in scope variable list. I added a new function to a stack frame:
lldb::VariableListSP
StackFrame::GetInScopeVariableList (bool get_file_globals);
This gets only variables that are in scope and they will be ordered such
that the variables from the current scope are first.
llvm-svn: 136745
|
| |
|
|
|
|
| |
object on successful adding of a module.
llvm-svn: 136744
|
| |
|
|
|
|
| |
a pointer would crash LLDB ; minor improvements in dynamic formatters lookup
llvm-svn: 136743
|
| |
|
|
| |
llvm-svn: 136742
|
| |
|
|
|
|
| |
This information is not used for anything yet.
llvm-svn: 136741
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
evaluations.
Modify lldbbench.py so that lldbtest.line_number() utility function is available to
BenchBase client as just line_number(), and modify lldbtest.py so that self.lldbExec
(the full path for the 'lldb' executable) is available to BenchBase client as well.
An example run of the test case on my MacBook Pro running Lion:
1: test_compare_lldb_to_gdb (TestRepeatedExprs.RepeatedExprsCase)
Test repeated expressions with lldb vs. gdb. ...
lldb_avg: 0.204339
gdb_avg: 0.205721
lldb_avg/gdb_avg: 0.993284
ok
llvm-svn: 136740
|
| |
|
|
|
|
|
| |
With a 'FirstDef' field right there, it is very confusing that FirstUse
refers to an instruction that may be a def.
llvm-svn: 136739
|
| |
|
|
| |
llvm-svn: 136738
|
| |
|
|
|
|
| |
Not especially pretty, but seems to work well enough. If this looks okay, I'll put together similar patches for Mips, PPC, and Alpha.
llvm-svn: 136737
|
| |
|
|
|
|
|
|
|
|
|
| |
This is either an invalid SlotIndex, or valno->def for the first value
defined inside the block. PHI values are not counted as defined inside
the block.
The FirstDef field will be used when estimating the cost of spilling
around a block.
llvm-svn: 136736
|
| |
|
|
| |
llvm-svn: 136735
|
| |
|
|
|
|
| |
Patch by Jim (Ningjie) Chen.
llvm-svn: 136734
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
appropriately between C++ static methods and non-static
methods. This bug made it impossible to call most static
methods, either because Clang did not recognize that a
method could be called without providing a "this"
parameter, or because Clang did not properly mangle the
name of the method when searching for it in the target.
Also added a testcase.
llvm-svn: 136733
|
| |
|
|
|
|
| |
malloc call.
llvm-svn: 136732
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PrefBoth constraint is used for blocks that ideally want a live-in
value both on the stack and in a register. This would be used by a block
that has a use before interference forces a spill.
Secondly, add the ChangesValue flag to BlockConstraint. This tells
SpillPlacement if a live-in value on the stack can be reused as a
live-out stack value for free. If the block redefines the virtual
register, a spill would be required for that.
This extra information will be used by SpillPlacement to more accurately
calculate spill costs when a value can exist both on the stack and in a
register.
The simplest example is a basic block that reads the virtual register,
but doesn't change its value. Spilling around such a block requires a
reload, but no spill in the block.
The spiller already knows this, but the spill placer doesn't. That can
sometimes lead to suboptimal regions.
llvm-svn: 136731
|
| |
|
|
|
|
| |
instruction's documentation to reference the landingpad and resume instructions.
llvm-svn: 136729
|
| |
|
|
| |
llvm-svn: 136728
|
| |
|
|
| |
llvm-svn: 136727
|
| |
|
|
|
|
|
| |
but it solves a layering violation since things in Support are not supposed to
use things in Transforms.
llvm-svn: 136726
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
has a single element. This disables the warning in cases where
there is a clear bug, but this is really rare (who uses arrays
with one element?) and it also silences a large class of false
positive issues with C89 code that is using tail padding in structs.
A better version of this patch would detect when an array is in
a tail position in a struct, but at least patch fixes the huge
false positives that are hitting postgres and other code.
llvm-svn: 136724
|
| |
|
|
|
|
| |
spam.
llvm-svn: 136723
|
| |
|
|
| |
llvm-svn: 136722
|
| |
|
|
| |
llvm-svn: 136721
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did not take the patch for ClangExpressionParser.cpp since there was a
recent change by Peter for the same line. Feel free to disagree. :-)
Reference:
----------------------------------------------------------------------
r136580 | pcc | 2011-07-30 15:42:24 -0700 (Sat, 30 Jul 2011) | 3 lines
Add reloc arg to standard JIT createJIT()
Fixes non-__APPLE__ build. Patch by Matt Johnson!
----------------------------------------------------------------------
Also, I ignore the part of the patch to remove the RegisterContextDarwin*.h/.cpp.
llvm-svn: 136720
|
| |
|
|
|
|
|
| |
enough to offer to investigate the underlying issue. Thanks to Doug for his
assistance as well.
llvm-svn: 136719
|
| |
|
|
| |
llvm-svn: 136718
|
| |
|
|
|
|
| |
statement inside a block. // rdar://9878420
llvm-svn: 136717
|
| |
|
|
|
|
|
|
|
| |
externally visable, create a local symbol to use in the CFE. If not, use the
function label itself.
Fixes PR10420.
llvm-svn: 136716
|
| |
|
|
| |
llvm-svn: 136713
|
| |
|
|
|
|
| |
The testcase looks extremely fragile, so I'm adding an assertion which should catch any cases like this.
llvm-svn: 136711
|
| |
|
|
|
|
| |
Someone with more cmake experience want to throw me a bone? :)
llvm-svn: 136709
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by eliminating the type ID from constructor, destructor, and
conversion function names. There are several reasons for this change:
- A given type (say, int*) isn't guaranteed to have a single, unique
type ID within a chain of PCH files. Hence, we could end up hashing
based on the wrong type ID, causing name lookup to fail.
- The mapping from types back to type IDs required one DenseMap
entry for every type that was ever deserialized, which was an
unacceptable cost to support just the name lookup of constructors,
destructors, and conversion functions. Plus, this mapping could
never actually work with chained or multiple PCH, based on the first
bullet.
Once we have eliminated the type from the hash function, these
problems go away, as does my horrible "reverse type remap" hack, which
was doomed from the start (see bullet #1 above) and far too
complicated.
However, note that removing the type from the hash function means that
all constructors, destructors, and conversion functions have the same
hash key, so I've updated the caller to double-check that the
declarations found have the appropriate name.
llvm-svn: 136708
|
| |
|
|
|
|
| |
well as the comments that explain them incorrectly.
llvm-svn: 136707
|
| |
|
|
|
|
| |
all initializer expressions have already been evaluated.
llvm-svn: 136706
|
| |
|
|
| |
llvm-svn: 136705
|
| |
|
|
|
|
| |
Use a more descriptive name so the code is more self-documenting.
llvm-svn: 136704
|
| |
|
|
|
|
| |
actually works.
llvm-svn: 136703
|
| |
|
|
|
|
|
|
|
| |
information including the fully preprocessed source file(s) and command line
arguments. The developer is asked to attach this diagnostic information to a
bug report.
rdar://9575623
llvm-svn: 136702
|
| |
|
|
|
|
| |
the virtual files the ASTReader has to handle. Specifically, this occurs when the reader is reading AST files that were created in memory and not written to disk. For example, when a user creates a chained PCH using command line flags. These virtual files are stored in MemoryBuffers in ChainIncludeSource.cpp, and then read back in by the ASTReader. This patch moves the management of these buffers into the ModuleManager, so that it becomes the authority on where these buffers are located.
llvm-svn: 136697
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
datatype already had a custom format
Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers:
- expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory),
if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target)
pointer to the Python code
Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used:
- Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target
llvm-svn: 136695
|
| |
|
|
|
|
| |
returned noErr. (+ minor cleanup)
llvm-svn: 136694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reader. This scheme permits an AST file to be loaded with its type IDs
shifted anywhere in the type ID space.
At present, the type indices are still allocated in the same boring
way they always have been, just by adding up the number of types in
each PCH file within the chain. However, I've done testing with this
patch by randomly sliding the base indices at load time, to ensure
that remapping is occurring as expected. I may eventually formalize
this in some testing flag, but loading multiple (non-chained) AST
files at once will eventually exercise the same code.
There is one known problem with this patch, which involves name lookup
of operator names (e.g., "x.operator int*()") in cases where multiple
PCH files in the chain. The hash function itself depends on having a
stable type ID, which doesn't happen with chained PCH and *certainly*
doesn't happen when sliding type IDs around. We'll need another
approach. I'll tackle that next.
llvm-svn: 136693
|
| |
|
|
|
|
| |
This unbreaks some tests.
llvm-svn: 136692
|