llvm-svn: 182531

Added logging for the OS plug-in python objects in OperatingSystemPython so we can see the python dictionary returned from the plug-in when logging is enabled.

llvm-svn: 182530

Changes after feedback:
Directly use function pointer, just to be safer on 10.8.

llvm-svn: 182529

live as long as they needed to.  This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.

To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression.  Hand-declared persistent
variables do this now.

<rdar://problem/13956311>

llvm-svn: 182528

llvm-svn: 182527

llvm-svn: 182526

rdar://problem/13359718

llvm-svn: 182524

Collect 'anonymous memory' info, if possible

llvm-svn: 182523

Summary: "W" bit value was not consistent in ContentPermissions enum. It should always be 2.

Reviewers: kledzik

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D810

llvm-svn: 182515

llvm-svn: 182514

Fixed ProcessMachCore to be able to locate the main executeable in the core file even if it doesn't start at a core file address range boundary. Prior to this we only checked the first bytes of each range in the core file for mach_kernel or dyld. Now we still do this, but if we don't find the mach_kernel or dyld anywhere, we go through all core file ranges and check every 0x1000 to see if we can find dyld or the mach_kernel.

Now that we can properly detect the mach_kernel at any address, we don't need to call "DynamicLoaderDarwinKernel::SearchForDarwinKernel(Process*)" anymore.

llvm-svn: 182513

Currently the fast-isel table generator recognizes registers, register
classes, and immediates for source pattern operands.  ValueType
operands are not recognized.  This is not a problem for existing
targets with fast-isel support, but will not work for targets like
PowerPC and SPARC that use types in source patterns.

The proposed patch allows ValueType operands and treats them in the
same manner as register classes.  There is no convenient way to map
from a ValueType to a register class, but there's no need to do so.
The table generator already requires that all types in the source
pattern be identical, and we know the register class of the output
operand already.  So we just assign that register class to any
ValueType operands we encounter.

No functional effect on existing targets.  Testing deferred until the
PowerPC target implements fast-isel.

llvm-svn: 182512

Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.

llvm-svn: 182511

Using PatLeaf rather than ImmLeaf when defining immediate predicates
prevents simple patterns using those predicates from being recognized
for fast instruction selection.  This patch replaces the immSExt16
PatLeaf predicate with two ImmLeaf predicates, imm32SExt16 and
imm64SExt16, allowing a few more patterns to be recognized (ADDI,
ADDIC, MULLI, ADDI8, and ADDIC8).  Using the new predicates does not
help for LI, LI8, SUBFIC, and SUBFIC8 because these are rejected for
other reasons, but I see no reason to retain the PatLeaf predicate.

No functional change intended, and thus no test cases yet.  This is
preliminary work for enabling fast-isel support for PowerPC.  When
that support is ready, we'll be able to test this function.

llvm-svn: 182510

llvm-svn: 182509

We are not working on a DAG and I ran into a number of problems when I enabled the vectorizations of 'diamond-trees' (trees that share leafs).
* Imroved the numbering API.
* Changed the placement of new instructions to the last root.
* Fixed a bug with external tree users with non-zero lane.
* Fixed a bug in the placement of in-tree users.

llvm-svn: 182508

llvm-svn: 182507

llvm-svn: 182506

Fixes <rdar://problem/13949982>

llvm-svn: 182505

- The return type should be a pointer to the class type.
- Make the condition more specific.

rdar://problem/13359718

llvm-svn: 182504

llvm-svn: 182503

These are legitimate control-flow edges, but visually they add
no value.

Implements <rdar://problem/13941325>.

llvm-svn: 182502

llvm-svn: 182501

llvm-svn: 182500

The earlier change list introduced the following inst combines:
B * (uitofp i1 C) —> select C, B, 0
A * (1 - uitofp i1 C) —> select C, 0, A
select C, 0, B + select C, A, 0 —> select C, A, B

Together these 3 changes would simplify :
A * (1 - uitofp i1 C) + B * uitofp i1 C 
down to :
select C, B, A

In practice we found that the first two substitutions can have a
negative effect on performance, because they reduce opportunities to
use FMA contractions; between the two options FMAs are often the
better choice.  This change list amends the previous one to enable
just these inst combines:

select C, B, 0 + select C, 0, A —> select C, B, A
A * (1 - uitofp i1 C) + B * uitofp i1 C —> select C, B, A

llvm-svn: 182499

This is important if the user has multiple Xcodes installed on their
system -- we use xcodebuild to do a version check, and therefore we need
to make sure we match the actual build command.

Reported by Howard Ling!

llvm-svn: 182498

Currently, blocks instantiated in templates lose their "signature as
written"; it's not clear if this is intentional. Change the analyzer's
use of BlockDecl::getSignatureAsWritten to check whether or not the
signature is actually there.

<rdar://problem/13954714>

llvm-svn: 182497

llvm-svn: 182496

llvm-svn: 182495

be laid out by their ordinal overrides first, there was a bug that two atoms may 
get the same override index due to which atoms were not ordered properly. This
commit fixes the problem.

Now the atoms are ordered by 

- Section Position hints
- Atom override (Using layout-after/layout-before/in-group)
- Content Permissions
- Content Type
- File Ordinal

This also fixes the problem of running c++ static executables that 
was broken by an earlier patch.

llvm-svn: 182494

llvm-svn: 182493

llvm-svn: 182491

constructors.  No functional change.
Part of rdar://12906217

llvm-svn: 182490

llvm-svn: 182488

This makes StringMap<> more compatible with std::map<std::string, ...>.

Differential Revision: http://llvm-reviews.chandlerc.com/D842

llvm-svn: 182487

Take #2 on fixing PR15977.

llvm-svn: 182486

The Value pointers we store in the induction variable list can be RAUW'ed by a
call to SCEVExpander::expandCodeFor, use a TrackingVH instead. Do the same thing
in some other places where we store pointers that could potentially be RAUW'ed.

Fixes PR16073.

llvm-svn: 182485

- no longer requires a pane name argument

Patch by Arthur Evstifeev

llvm-svn: 182484

patch by Arthur Evstifeev

llvm-svn: 182483

llvm-svn: 182482