llvm-svn: 117646

anyone has ever intentionally done this outside of a compiler test case.

llvm-svn: 117645

and never defined.  We were previously emitting these with default
visibility unless they were declared with private_extern.

Ignore global visibility settings when computing visibility for
a declaration's context, and key several conditions on whether a
visibility attribute exists anywhere in the hierarchy as opposed
to whether it exists at the current level.

llvm-svn: 117644

llvm-svn: 117643

llvm-svn: 117642

by type ID (the most common type of type lookup).

Changed the API logging a bit to always show the objects in the OBJECT(POINTER)
format so it will be easy to locate all instances of an object or references
to it when looking at logs.

llvm-svn: 117641

This isn't used yet, because someone more experienced than I needs to look
at the type system about gutting getCanonicalCallConv().

llvm-svn: 117638

With Python-2.4, Reader::read64 always returns (unexpected) long integer.
FileCheck detects failure on test/MC/MachO among '0' and '0L'.

CentOS5(aka RHEL5 clone) provides python-2.4.

llvm-svn: 117637

from constant memory don't alias any stores.

llvm-svn: 117636

Fixes <rdar://problem/8601243>.

llvm-svn: 117635

llvm-svn: 117634

llvm-svn: 117633

llvm-svn: 117632

EquvivalenceClasses.h except it looks like overkill when elements are continuous
integers.

llvm-svn: 117631

multiplicity.

llvm-svn: 117630

llvm-svn: 117629

of its context without considering global settings like -fvisibility=hidden.
Fixes PR8492.

llvm-svn: 117628

which holds the name of a file whose contents are
prefixed to each expression.  For example, if the file
~/lldb.prefix.header contains:

typedef unsigned short my_type;

then you can do this:

(lldb) settings set target.expr-prefix '~/lldb.prefix.header'
(lldb) expr sizeof(my_type)
(unsigned long) $0 = 2

When the variable is changed, the corresponding file
is loaded and its contents are fetched into a string
that is stored along with the target.  This string
is then passed to each expression and inserted into
it during parsing, like this:

typedef unsigned short my_type;
                             
void                           
$__lldb_expr(void *$__lldb_arg)          
{                              
    sizeof(my_type);                        
}

llvm-svn: 117627

vldr.64 to work.  I have no idea if this is fully right, but 
it is in the right direction.

llvm-svn: 117626

(A PR will be linked to this rev.)

llvm-svn: 117620

llvm-svn: 117618

arguments, to help text for alias commands.

llvm-svn: 117617

command.

llvm-svn: 117616

llvm-svn: 117615

llvm-svn: 117613

version);  change include statements to use Python.h in the Python framework
on Mac OS X systems; leave it using regular Python.h on other systems.

Note:  I think this *ought* to work properly on Linux systems, but I don't have
a system to test it on...

llvm-svn: 117612

t.s:1:14: error: invalid operand for instruction
vldr.64	d17, [r0]   
       	     ^

instead of:

t.s:1:1: error: unrecognized instruction
vldr.64	d17, [r0]   
^

llvm-svn: 117611

using the memory type;  fixes an assert.

Fixes rdar://problem/8605032

llvm-svn: 117610

the opcode string in the inst dump, e.g.:
	vmov	r2, r3, d17             @ encoding: [0x31,0x2b,0x53,0xec]
                                        @ <MCInst #989 VMOVRRD
                                        @  <MCOperand Reg:68>
                                        @  <MCOperand Reg:69>
                                        @  <MCOperand Reg:19>
                                        @  <MCOperand Imm:14>
                                        @  <MCOperand Reg:0>>

The "VMOVRRD" is new.

llvm-svn: 117609

* If we have a M or a G, reject sections without the type
* Only parse the flag specific arguments if we have M or G
* Parse the corresponding arguments for M and G

We ignore the G arguments and flag for now.

llvm-svn: 117608

it looks like we're not handling [] operands though

llvm-svn: 117607

(like ARM) correctly.  With this change, we can now match "bx lr"
because we recognize lr as a register.

llvm-svn: 117606

llvm-svn: 117605

llvm-svn: 117604

llvm-svn: 117603

llvm-svn: 117602

llvm-svn: 117601

llvm-svn: 117600

in SSAUpdaterImpl.h

Verifying live intervals revealed that the old method was completely wrong, and
we need an iterative approach to calculating PHI placemant. Fortunately, we have
MachineDominators available, so we don't have to compute that over and over
like SSAUpdaterImpl.h must.

Live-out values are cached between calls to mapValue() and computed in a greedy
way, so most calls will be working with very small block sets.

Thanks to Bob for explaining how this should work.

llvm-svn: 117599

proper SSA updating.

This doesn't cause MachineDominators to be recomputed since we are already
requiring MachineLoopInfo which uses dominators as well.

llvm-svn: 117598