say either "array type" or "function type", whichever it is. No reason
to make the user guess.

llvm-svn: 93164

have a fix.

llvm-svn: 93163

(C++ [temp.mem]p5-6), which involves template argument deduction based
on the type named, e.g., given

  struct X { template<typename T> operator T*(); } x;

when we call

  x.operator int*();

we perform template argument deduction to determine that T=int. This
template argument deduction is needed for template specialization and
explicit instantiation, e.g.,

  template<> X::operator float*() { /* ... */ }

and when calling or otherwise naming a conversion function (as in the
first example). 

This fixes PR5742 and PR5762, although there's some remaining ugliness
that's causing out-of-line definitions of conversion function
templates to fail. I'll look into that separately.

llvm-svn: 93162

- getToken is modeled after StringRef::split but it can split on multiple
  separator chars and skips leading seperators.
- SplitString is a StringRef::split variant for more than 2 elements with the
  same behaviour as getToken.

llvm-svn: 93161

has an immediate with at least 32 bits of leading zeros, to avoid needing to
materialize that immediate in a register first.

FileCheckize, tidy, and extend a testcase to cover this case.

This fixes rdar://7527390.

llvm-svn: 93160

in a function. Fixes radar 7522803.

llvm-svn: 93159

new AsmPrinter. This is perhaps less elegant than describing them
in terms of MOV32r0 and subreg operations, but it allows the
current register to rematerialize them.

llvm-svn: 93158

llvm-svn: 93157

llvm-svn: 93156

single user. The _su forms are intended for non-top-level nodes.

llvm-svn: 93155

llvm-svn: 93154

"ASTContext::getTypeSize() / 8". Replace [u]int64_t variables with CharUnits
ones as appropriate. 

Also rename RawType, fromRaw(), and getRaw() in CharUnits to QuantityType, 
fromQuantity(), and getQuantity() for clarity.

llvm-svn: 93153

Select an OR with immediate as an ADD if the input bits are known zero. This allow the instruction to be 3address-fied if needed.

llvm-svn: 93152

Implement a feature (-vector-unaligned-mem) to allow targets to
ignore alignment requirements for SIMD memory operands.  This
is useful on architectures like the AMD 10h that do not trap on
unaligned references if a status bit is twiddled at startup time.

llvm-svn: 93151

llvm-svn: 93150

Make InsertDbgValueIntrinsic() and get Offset take and recieve a uint64_t.
Get constness correct for getVariable() and getValue().

llvm-svn: 93149

The old test case has a little mistake.

llvm-svn: 93148

good code on PR4216:

_test_bitfield:                                             ## @test_bitfield
	orl	$32962, %edi
	movl	$4294941946, %eax
	andq	%rdi, %rax
	ret

instead of:

_test_bitfield:
        movl    $4294941696, %ecx
        movl    %edi, %eax
        orl     $194, %edi
        orl     $32768, %eax
        andq    $250, %rdi
        andq    %rax, %rcx
        movq    %rdi, %rax
        orq     %rcx, %rax
        ret

Evan is looking into the remaining andq+imm -> andl optimization.

llvm-svn: 93147

This with previous patch fixes a OSAtomic test case.

llvm-svn: 93146

BitsToClear case.  This allows it to promote expressions which have an
and/or/xor after the lshr, promoting cases like test2 (from PR4216) 
and test3 (random extample extracted from a spec benchmark).

clang now compiles the code in PR4216 into:

_test_bitfield:                                             ## @test_bitfield
	movl	%edi, %eax
	orl	$194, %eax
	movl	$4294902010, %ecx
	andq	%rax, %rcx
	orl	$32768, %edi
	andq	$39936, %rdi
	movq	%rdi, %rax
	orq	%rcx, %rax
	ret

instead of:

_test_bitfield:                                             ## @test_bitfield
	movl	%edi, %eax
	orl	$194, %eax
	movl	$4294902010, %ecx
	andq	%rax, %rcx
	shrl	$8, %edi
	orl	$128, %edi
	shlq	$8, %rdi
	andq	$39936, %rdi
	movq	%rdi, %rax
	orq	%rcx, %rax
	ret

which is still not great, but is progress.

llvm-svn: 93145

new BitsToClear result which allows us to start promoting
expressions that end with a lshr-by-constant.  This is
conservatively correct and better than what we had before
(see testcases) but still needs to be extended further.

llvm-svn: 93144

llvm-svn: 93143

llvm-svn: 93141

value bindings.  Along with a small change to OSAtomicChecker, this
resolves <rdar://problem/7527292> and resolves some long-standing
issues with how values can be bound to the same physical address by
not have the same "key".  This change is only a beginning; logically
RegionStore needs to better handle loads from addresses where the
stored value is larger/smaller/different type than the loaded value.
We handle these cases in an approximate fashion now (via
CastRetrievedVal and help in SimpleSValuator), but it could be made
much smarter.

llvm-svn: 93137

(1) Introduce a new 'BindingKey' class to match 'BindingValue'.  This
gives us the flexibility to change the current key value from 'const
MemRegion*' to something more interesting.

(2) Rework additions/removals/lookups from the store to use new
'Remove', 'Add', 'Lookup' utility methods.

No "real" functionality change; just prep work and abstraction.

llvm-svn: 93136

incompatible with user-defined literals, specifically with the following form:

  0x1p+1

The preprocessing-number token extends only as far as the 'p'; the '+' is not
included. Previously we could get away with this extension as p was an invalid
suffix, but now with user-defined literals, 'p' might well be a valid suffix
and we are forced to consider it as such.

This patch also adds a warning in non-0x C++ modes telling the user that
this extension is incompatible with C++0x that is enabled by default
(previously and with other languages, we warn only with a compliance
option such as -pedantic).

llvm-svn: 93135

C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for

  static_cast<type>(expr)

when we can have an expression, or

  using namespace identifier;

when we can have a using directive.

Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.

llvm-svn: 93134

llvm-svn: 93133

the dest of the sext.

llvm-svn: 93128

the zext dest type.  This allows us to handle test52/53 in cast.ll,
and allows llvm-gcc to generate much better code for PR4216 in -m64
mode:

_test_bitfield:                                             ## @test_bitfield
	orl	$32962, %edi
	movl	%edi, %eax
	andl	$-25350, %eax
	ret

This also fixes a bug handling vector extends, ensuring that the
mask produced is a vector constant, not an integer constant.

llvm-svn: 93127

integer vectors as well as just integers.

llvm-svn: 93126

RewriteObjC.cpp(4419) : warning C4804: '>' : unsafe use of type 'bool' in operation

llvm-svn: 93124

warning: suggest parentheses around ‘&&’ within ‘||’.
llvm-svn: 93121

llvm-svn: 93120

llvm-svn: 93119

 1. Add helper class for sema checks for target attributes
 2. Add helper class for codegen of target attributes

As a proof-of-concept - implement msp430's 'interrupt' attribute.

llvm-svn: 93118

llvm-svn: 93117

llvm-svn: 93114

simpler profitability predicate.

llvm-svn: 93111

llvm-svn: 93110