not sizes;  so that we use well-typed allocas;  and so that we
properly recurse through the full set of variably-modified types.

llvm-svn: 133827

llvm-svn: 133826

in fragile abi mode and some other cleanups. // rdar://8940528

llvm-svn: 133747

in Darwin's fragile abi mode.  // rdar://8940528

llvm-svn: 133639

llvm-svn: 133623

objects, so that we steal the retain count of a temporary __strong
pointer (zeroing out that temporary), eliding a retain/release
pair. Addresses <rdar://problem/9364932>.

llvm-svn: 133621

retain/release the temporary object appropriately. Previously, we
would only perform the retain/release operations when the reference
would extend the lifetime of the temporary, but this does the wrong
thing across calls.

llvm-svn: 133620

that takes an ArrayRef.

llvm-svn: 133615

existence by always threading an edge from the catchall.  Not doing
this was previously causing a crash in the very extreme case where
neither the normal cleanup nor the EH catchall was actually reachable:
we would delete the catchall entry block, which would cause us to
delete the entry block of the finally cleanup as well because the
cleanup logic would merge the blocks, which in turn triggered an assert
because later blocks in the finally would still be using values from the
entry.  Laziness turns out to be the most elegant solution to the problem.

llvm-svn: 133601

 - Changes bit-field access policy to try to use (aligned) register sized accesses.

The idea here is that by using larger accesses we expose more coalescing
potential to the backend when we have situations like adjacent bit-fields in the
same structure (which is common), and that the backend should be smart enough to
narrow the accesses down when no coalescing is done or when it is shown not to
be profitable.

--
$ clang -m32 -O3 -S -o - t.c
_f0:                                    ## @f0
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %eax
	movb	(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, (%eax)
	movb	1(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 1(%eax)
	movb	2(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 2(%eax)
	movb	3(%eax), %cl
	andb	$-128, %cl
	orb	$1, %cl
	movb	%cl, 3(%eax)
	popl	%ebp
	ret

$ clang -m32 -O3 -S -o - t.c -Xclang -fuse-register-sized-bitfield-access
_f0:                                    ## @f0
	pushl	%ebp
	movl	%esp, %ebp
	movl	8(%ebp), %eax
	movl	$-2139062144, %ecx      ## imm = 0xFFFFFFFF80808080
	andl	(%eax), %ecx
	orl	$16843009, %ecx         ## imm = 0x1010101
	movl	%ecx, (%eax)
	popl	%ebp
	ret
--

llvm-svn: 133532

llvm-svn: 133530

llvm-svn: 133528

MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given

  const int& r = 1.0;

The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value. 

IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.

llvm-svn: 133521

llvm-svn: 133501

an assembly file it worked correctly, while for a .c file it would given an
error about how --noexecstack is not a supported argument to -Wa.

llvm-svn: 133489

Fixes rdar://9425559

llvm-svn: 133486

(or follow up) extern declaration with weak_import as 
an actual definition. make clang follows this behavior. 
// rdar://9538608
llvm-gcc treats an extern declaration with weak_import

llvm-svn: 133450

Change PHINodes to store simple pointers to their incoming basic blocks,
instead of full-blown Uses.

Note that this loses an optimization in SplitCriticalEdge(), because we
can no longer walk the use list of a BasicBlock to find phi nodes. See
the comment I removed starting "However, the foreach loop is slow for
blocks with lots of predecessors".

Extend replaceAllUsesWith() on a BasicBlock to also update any phi
nodes in the block's successors. This mimics what would have happened
when PHINodes were proper Users of their incoming blocks. (Note that
this only works if OldBB->replaceAllUsesWith(NewBB) is called when
OldBB still has a terminator instruction, so it still has some
successors.)

llvm-svn: 133435

llvm-svn: 133418

ConvertType on InitListExprs as they are being converted.  This is
needed for a forthcoming patch, and improves the IR generated anyway
(see additional type names in testcases). 

This patch also converts a bunch of std::vector's in CGObjCMac to use
C arrays.  There are a ton more that should be converted as well.

llvm-svn: 133413

llvm-svn: 133365

llvm-svn: 133346

llvm-svn: 133345

separate aggregate temporary and then memcpy it over to the
destination. This fixes a regression I introduced with r133235, where
the compound literal on the RHS of an assignment makes use of the
structure on the LHS of the assignment.

I'm deeply suspicious of AggExprEmitter::VisitBinAssign()'s
optimization where it emits the RHS of an aggregate assignment
directly into the LHS lvalue without checking whether there is any
aliasing between the LHS/RHS. However, I'm not in a position to
revisit this now.

Big thanks to Eli for finding the regression!

llvm-svn: 133261

static initializer check, as required by the Itanium ABI.

llvm-svn: 133250

they should still be officially __strong for the purposes of errors, 
block capture, etc.  Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables.  Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting         
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.

llvm-svn: 133243

C++, which means:
  - binding the temporary as needed in Sema, so that we generate the
  appropriate call to the destructor, and
  - emitting the compound literal into the appropriate location for
  the aggregate, rather than trying to emit it as a temporary and
  memcpy() it.

Fixes PR10138 / <rdar://problem/9615901>.

llvm-svn: 133235

register constraint. Note that we're not checking if the register itself
is valid for the constraint.

Fixes rdar://9382985

llvm-svn: 133226

getLVForNamespaceScopeDecl(). // rdar://9609649

llvm-svn: 133182

declaration of global var is __private_extern__.
// rdar://9609649

llvm-svn: 133157

llvm-svn: 133144

llvm-svn: 133110

Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.

Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.

llvm-svn: 133103

llvm-svn: 133095

Use isAnyComplexType here so we don't pass complex numbers into the aggregate handling code; found by inspection.

llvm-svn: 133070

llvm-svn: 133069

- llvm.dbg.declare already receives line number information from ParmDecl
- Additional extra stoppoint messes up gdb's understanding of where function body starts.

llvm-svn: 133065

whether it's a data or instruction cache access.

llvm-svn: 132977

llvm-svn: 132973

The LLVM IR representation of byval arguments has a rather strange property: if the alignment of an argument to a call is less than the specified byval alignment for that argument, there is no way to specify the alignment of the implied copy.  Therefore, we must ensure that the alignment of the argument is at least the byval alignment.  To do this, we have to mess with the alignment of relevant alloca's in some cases, and insert a copy that conceptually shouldn't be necessary in some cases.

This patch tries relatively hard to avoid creating an extra copy if it can be avoided (see test3 in the included testcase), but it is not possible to avoid in some cases (like test2 in the included testcase).

rdar://9483886

llvm-svn: 132957