completed a successful build.

llvm-svn: 109815

llvm-svn: 109814

llvm-svn: 109813

llvm-svn: 109810

llvm-svn: 109809

Objective-C object and interface types. This is part of PR7741.

llvm-svn: 109808

that needs it and remove getCoerceResult.

llvm-svn: 109807

llvm-svn: 109806

llvm-svn: 109805

float, the special case hack in getCoerceResult can go away.

llvm-svn: 109804

llvm-svn: 109803

llvm-svn: 109802

llvm-svn: 109801

transformations.

llvm-svn: 109800

integers with mov + vdup.  8003375.  This is
currently disabled by default because LICM will
not hoist a VDUP, so it pessimizes the code if
the construct occurs inside a loop (8248029).

llvm-svn: 109799

llvm-svn: 109798

llvm-svn: 109797

Weak references and variables that are not definitions are not required for early codegen/deserialization.

llvm-svn: 109796

Fixed "void *ClangASTContext::CreatePointerType (void *clang_type);" to return objective C pointers for clang::Type::TypeClass types that are "clang::Type::ObjCObject" and "clang::Type::ObjCInterface" .

llvm-svn: 109795

llvm-svn: 109794

parens and to have a space before the value.

Before:
(lldb) expr 3 + 1
int4

(lldb) expr 3 + 1
(int) 4

llvm-svn: 109793

code model with the JIT.

llvm-svn: 109792

llvm-svn: 109791

<2 x float> instead of double.  This works but can't be turned
on until I teach codegen to pass <2 x float> as one XMM register
instead of two.

llvm-svn: 109790

PR7745.

llvm-svn: 109788

llvm-svn: 109787

llvm-svn: 109786

llvm-svn: 109785

DeclIsRequiredFunctionOrFileScopedVar.

This is essentially a CodeGen predicate that is also needed by the PCH mechanism to determine whether a decl
needs to be deserialized during PCH loading for codegen purposes.
Since this logic is shared by CodeGen and the PCH mechanism, move it to the ASTContext,
thus CodeGenModule's GetLinkageForFunction/GetLinkageForVariable and the GVALinkage enum is moved out of CodeGen.

This fixes current (and avoids future) codegen-from-PCH bugs.

llvm-svn: 109784

end of a struct.  This improves the case when the struct being passed
contains 3 floats, either due to a struct or array of 3 things.  Before
we'd generate this IR for the testcase:

define float @bar(double %X.coerce0, double %X.coerce1) nounwind {
entry:
  %X = alloca %struct.foof, align 8               ; <%struct.foof*> [#uses=2]
  %0 = bitcast %struct.foof* %X to %1*            ; <%1*> [#uses=2]
  %1 = getelementptr %1* %0, i32 0, i32 0         ; <double*> [#uses=1]
  store double %X.coerce0, double* %1
  %2 = getelementptr %1* %0, i32 0, i32 1         ; <double*> [#uses=1]
  store double %X.coerce1, double* %2
  %tmp = getelementptr inbounds %struct.foof* %X, i32 0, i32 2 ; <float*> [#uses=1]
  %tmp1 = load float* %tmp                        ; <float> [#uses=1]
  ret float %tmp1
}

which compiled (with optimization) to:

_bar:                                   ## @bar
## BB#0:                                ## %entry
	movd	%xmm1, %rax
	movd	%eax, %xmm0
	ret

Now we produce:

define float @bar(double %X.coerce0, float %X.coerce1) nounwind {
entry:
  %X = alloca %struct.foof, align 8               ; <%struct.foof*> [#uses=2]
  %0 = bitcast %struct.foof* %X to %0*            ; <%0*> [#uses=2]
  %1 = getelementptr %0* %0, i32 0, i32 0         ; <double*> [#uses=1]
  store double %X.coerce0, double* %1
  %2 = getelementptr %0* %0, i32 0, i32 1         ; <float*> [#uses=1]
  store float %X.coerce1, float* %2
  %tmp = getelementptr inbounds %struct.foof* %X, i32 0, i32 2 ; <float*> [#uses=1]
  %tmp1 = load float* %tmp                        ; <float> [#uses=1]
  ret float %tmp1
}

and:

_bar:                                   ## @bar
## BB#0:                                ## %entry
	movaps	%xmm1, %xmm0
	ret

llvm-svn: 109776

llvm-svn: 109775

llvm-svn: 109774

if CExpr is a ConstantInt.

llvm-svn: 109773

llvm-svn: 109772

llvm-svn: 109771

Add intrinsics __builtin_arm_qadd & __builtin_arm_qsub to allow access to the QADD & QSUB instructions.
Behave identically to __qadd & __qsub RealView instruction intrinsics.

llvm-svn: 109770

message is properly contaminated with nonsense about timing passes
that doesn't apply at all to this utility. :)

llvm-svn: 109769

as <2 x float> instead of as double.  The backend isn't ready
yet, but infrastructure in the frontend can come up.

llvm-svn: 109768

Plug the remaining MC leaks by giving MCObjectStreamer/MCAsmStreamer ownership of the TargetAsmBackend and the MCCodeEmitter.

llvm-svn: 109767

llvm-svn: 109766