Implemented by making lib/CompilerDriver a shared library that holds all the
global static data (CommandLine options, plugin registry) that we unfortunately
have to live with.

llvm-svn: 74417

llvm-svn: 74416

llvm-svn: 74415

llvm-svn: 74414

llvm-svn: 74413

llvm-svn: 74412

The issue this was working around is no longer present in TOT clang.

llvm-svn: 74411

llvm-svn: 74410

handled by RetrieveArray().

llvm-svn: 74409

symbol.

llvm-svn: 74408

llvm-svn: 74407

memregion.

llvm-svn: 74406

function attributes. There are predefined macros that are defined when stack
protectors are used: __SSP__=1 with -fstack-protector and __SSP_ALL__=2 with
-fstack-protector-all.

llvm-svn: 74405

Handle rules for ExtVector + ExtVector and ExtVector + Scalar operations. 
Fix problem Eli noticed where we were allowing pointer types to be splatted to
vector elements.

llvm-svn: 74404

llvm-svn: 74402

llvm-svn: 74401

llvm-svn: 74400

doesn't have an IV-based operand. This fixes PR4471.

llvm-svn: 74399

LoopInfo will handle removing it from the Loop, as well as updating
its own tables.

llvm-svn: 74398

llvm-svn: 74397

when one of them can be converted to a trivial icmp and conditional
branch.

This addresses what is essentially a phase ordering problem.
SimplifyCFG knows how to do this transformation, but it doesn't do so
if the primary block has any instructions in it other than an icmp and
a branch. In the given testcase, the block contains other instructions,
however they are loop-invariant and can be hoisted. SimplifyCFG doesn't
have LoopInfo though, so it can't hoist them. And, it's important that
the blocks be merged before LoopRotation, as it doesn't support
multiple-exit loops.

llvm-svn: 74396

llvm-svn: 74395

llvm-svn: 74394

of a team of individual allocations and a team of std::maps.

llvm-svn: 74393

llvm-svn: 74392

llvm-svn: 74391

llvm-svn: 74390

llvm-svn: 74389

out an error for a malformed __builtin_offsetof.

llvm-svn: 74388

llvm-svn: 74387

llvm-svn: 74386

llvm-svn: 74385

llvm-svn: 74384

making sure we return true when annotating a function template with 
explicit template arguments, but not when we don't annotate anything.)

llvm-svn: 74383

llvm-svn: 74382

it doesn't actually work yet; we just error out a bit more gracefully.

llvm-svn: 74381

parameter has a dependent type.

llvm-svn: 74380

target-specific operand printing functionality.  Yay.

llvm-svn: 74379

llvm-svn: 74378

llvm-svn: 74377