llvm-svn: 59371

llvm-svn: 59370

llvm-svn: 59362

use SHUFFLE_VECTOR instead.  If not practical, fall back
to the old scheme of building the split result by hand
using a BUILD_VECTOR.

llvm-svn: 59361

llvm-svn: 59359

llvm-svn: 59358

and when loading/storing a widen vector, make sure that they are loaded
and stored in consecutive order.

llvm-svn: 59357

llvm-svn: 59356

llvm-svn: 59355

llvm-svn: 59354

llvm-svn: 59353

Add a test case for compound assignments that lazily symbolicate the value of the LHS when the computation type is an integer of more bits.

llvm-svn: 59352

Reverted part of r59335: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20081110/009243.html
In that patch I added a bogus type promotion for unary '!'.

The real bug was more fallout from edges cases with compound assignments and conjured symbolic values.  Now the conjured value has the type of the LHS expression, and we do a promotion to the computation type.  We also now correctly do a conversion from the computation type back to the LHS type.

llvm-svn: 59349

llvm-svn: 59348

dummy library, `llvm_headers_do_not_build', is created for containing
all header and TableGen files under include/llvm.

llvm-svn: 59346

llvm-svn: 59345

llvm-svn: 59344

llvm-svn: 59343

include/llvm/CMakeLists.txt. Does it with the `tablegen' cmake macro.

llvm-svn: 59342

llvm-svn: 59341

llvm-svn: 59340

Implement FIXME in GRExprEngine::VisitUnaryOperator() to handle implicit conversions caused by the '!' operator.  This required adding some logic to GRSimpleVals to reason about nonloc::LocAsInteger SVals.  This code appears to work fine, but it should eventually be cleaned up.

llvm-svn: 59335

llvm-svn: 59334

llvm-svn: 59333

llvm-svn: 59332

Thanks to Doug for the review. Actual effects of mutable to follow.

llvm-svn: 59331

Thanks to Sebastian for the suggestion.

llvm-svn: 59330

Strip debug information before stripping symbol names. 

llvm-svn: 59328

consistency.

Patch by Kevin Andre!

llvm-svn: 59326

files.

llvm-svn: 59325

fairly conservative; it doesn't do alias-analysis queries and it doesn't
attempt to break anti-dependencies.

llvm-svn: 59324

llvm-svn: 59323

SynthBlockInitExpr() was not adding by-ref arguments to the init expr.

llvm-svn: 59322

- Block-expression for 'ObjCForCollectionStmt' is not alive before it occurs
- Recursively visit 'element' expression for ObjCForCollectionStmt to get liveness for referenced block-level expressions and variables.

llvm-svn: 59316

llvm-svn: 59314

Second attempt at implementation transfer function support for ObjCForCollectionStmt.  We now assume that the 'element' expression can be any lvalue.

llvm-svn: 59313

Flow-sensitive uninitialized values analysis: properly handle the 'element' expression of ObjCForCollectionStmt (can be anything).

llvm-svn: 59312

llvm-svn: 59311

registering XCoreTargetMachine.

llvm-svn: 59308

function call created in response to the use of operator syntax that
resolves to an overloaded operator in C++, e.g., "str1 +
str2" that resolves to std::operator+(str1, str2)". We now build a
CXXOperatorCallExpr in C++ when we pick an overloaded operator. (But
only for binary operators, where we actually implement overloading)

I decided *not* to refactor the current CallExpr to make it abstract
(with FunctionCallExpr and CXXOperatorCallExpr as derived
classes). Doing so would allow us to make CXXOperatorCallExpr a little
bit smaller, at the cost of making the argument and callee accessors
virtual. We won't know if this is going to be a win until we can parse
lots of C++ code to determine how much memory we'll save by making
this change vs. the performance penalty due to the extra virtual
calls.

llvm-svn: 59306