typemaps to allow Python to invoke the new SBModule::GetVersion() API. Memory management is taken care of automatically so that Python users can simply say my_list = my_module.GetVersion() and receive a new list with the version numbers, if any, inside.

llvm-svn: 151271

llvm-svn: 151270

Assuming that a single std::set node adds 3 control words, a bitvector
can store (3*8+4)*8=224 registers in the allocated memory of a single
element in the std::set (x86_64). Also we don't have to call malloc
for every register added.

llvm-svn: 151269

must still auto synthesize those propeties which have been redeclared 
in the class. // rdar://10907410

llvm-svn: 151268

rdar://10873652

As part of this I updated the llvm-mc disassembler C API to always call the
SymbolLookUp call back even if there is no getOpInfo call back.  If there is a
getOpInfo call back that is tried first and then if that gets no information
then the  SymbolLookUp is called.  I also made the code more robust by
memset(3)'ing to zero the LLVMOpInfo1 struct before then setting
SymbolicOp.Value before for the call to getOpInfo.  And also don't use any
values from the  LLVMOpInfo1 struct if getOpInfo returns 0.  And also don't
use any of the ReferenceType or ReferenceName values from SymbolLookUp if it
returns NULL. rdar://10873563 and rdar://10873683

For the X86 target also fixed bugs so the annotations get printed. 

Also fixed a few places in the ARM target that was not producing symbolic
operands for some instructions.  rdar://10878166

llvm-svn: 151267

Also, some basic clean up.  Patch by Evandro Menezes.

llvm-svn: 151266

Before register allocation, instructions can be moved across calls in
order to reduce register pressure.  After register allocation, we don't
gain a lot by moving callee-saved defs across calls.  In fact, since the
scheduler doesn't have a good idea how registers are used in the callee,
it can't really make good scheduling decisions.

This changes the schedule in two ways: 1. Latencies to call uses and
defs are no longer accounted for, causing some random shuffling around
calls.  This isn't really a problem since those uses and defs are
inaccurate proxies for what happens inside the callee.  They don't
represent registers used by the call instruction itself.

2. Instructions are no longer moved across calls.  This didn't happen
very often, and the scheduling decision was made on dubious information
anyway.

As with any scheduling change, benchmark numbers shift around a bit,
but there is no positive or negative trend from this change.

This makes the post-ra scheduler 5% faster for ARM targets.

The secret motivation for this patch is the introduction of register
mask operands representing call clobbers.  The most efficient way of
handling regmasks in ScheduleDAGInstrs is to model them as barriers for
physreg live ranges, but not for virtreg live ranges.  That's fine
pre-ra, but post-ra it would have the same effect as this patch.

llvm-svn: 151265

llvm-svn: 151264

llvm-svn: 151263

llvm-svn: 151262

llvm-svn: 151261

llvm-svn: 151260

isTrivial() call.

llvm-svn: 151259

Replace some DenseSets with SmallPtrSets. Apart from the "small" optimization, the current implementation is also a denser.

llvm-svn: 151257

I had originally made the handler function pointers a static internal detail, not accessible to the outside world.  I did this because they must be accessed in a thread-safe manner, and the library provides thread-safe getters and setters for these.  However I am at least temporarily making them public and giving them the Apple-extension names.  In the future these may disappear again, and I think that would probably be a good idea.

llvm-svn: 151256

Unique CXXBasePath decls with the SmallVector/pod_sort/std::unique idiom instead of employing a wasteful std::set.

llvm-svn: 151255

llvm-svn: 151254

llvm-svn: 151252

llvm-svn: 151251

of instantiated C++ templates.

Patch by Kristof Beyls!

llvm-svn: 151250

llvm-svn: 151249

llvm-svn: 151248

it with memcpy. This also fixes a problem on big-endian hosts, where
addUnaligned would return different results depending on the alignment
of the data.

llvm-svn: 151247

llvm-svn: 151246

forget the vptrs.

llvm-svn: 151245

used if IsInDevelopmentTree is 'true'.  But it doesn't, so help it out.

llvm-svn: 151244

llvm-svn: 151243

returns 'true' and emits a warning.  Help it out.

llvm-svn: 151242

llvm-svn: 151241

compiler support for the std::is_trivially_assignable library type
trait.

llvm-svn: 151240

llvm-svn: 151239

llvm-svn: 151238

* Handle some situations where we should never make a decl more visible,
  even when merging in an explicit visibility.

* Handle attributes in members of classes that are explicitly specialized.

Thanks Nico for the report and testing, Eric for the initial review, and dgregor
for the awesome test27 :-)

llvm-svn: 151236

llvm-svn: 151235

llvm-svn: 151234

Ignore undef uses completely.
Use a more explicit SlotIndex API.
Add more explicit comments.

llvm-svn: 151233

  - Apparently, SVN is yellow
  - Note that initializer lists are "in progress"

llvm-svn: 151232

llvm-svn: 151231

of x are zero. This optimizes rev + lsr 16 to rev16.

rdar://10750814

llvm-svn: 151230

Try to handle qualifiers more consistently for array InitListExprs.  Fixes <rdar://problem/10907510>, and makes the ASTs a bit more self-consistent.

(I've chosen to keep the qualifiers, but it isn't a strong preference; if anyone prefers removing them, please yell.)

llvm-svn: 151229