when A==B, -0.0 != +0.0.

llvm-svn: 63474

llvm-svn: 63473

llvm-svn: 63472

llvm-svn: 63471

alignment.

llvm-svn: 63470

be able to handle *ANY* alloca that is poked by loads and stores of 
bitcasts and GEPs with constant offsets.  Before the code had a number
of annoying limitations and caused it to miss cases such as storing into
holes in structs and complex casts (as in bitfield-sroa) where we had
unions of bitfields etc.  This also handles a number of important cases
that are exposed due to the ABI lowering stuff we do to pass stuff by
value.

One case that is pretty great is that we compile 
2006-11-07-InvalidArrayPromote.ll into:

define i32 @func(<4 x float> %v0, <4 x float> %v1) nounwind {
	%tmp10 = call <4 x i32> @llvm.x86.sse2.cvttps2dq(<4 x float> %v1)
	%tmp105 = bitcast <4 x i32> %tmp10 to i128
	%tmp1056 = zext i128 %tmp105 to i256	
	%tmp.upgrd.43 = lshr i256 %tmp1056, 96
	%tmp.upgrd.44 = trunc i256 %tmp.upgrd.43 to i32	
	ret i32 %tmp.upgrd.44
}

which turns into:

_func:
	subl	$28, %esp
	cvttps2dq	%xmm1, %xmm0
	movaps	%xmm0, (%esp)
	movl	12(%esp), %eax
	addl	$28, %esp
	ret

Which is pretty good code all things considering :).

One effect of this is that SROA will start generating arbitrary bitwidth 
integers that are a multiple of 8 bits.  In the case above, we got a 
256 bit integer, but the codegen guys assure me that it can handle the 
simple and/or/shift/zext stuff that we're doing on these operations.

This addresses rdar://6532315

llvm-svn: 63469

llvm-svn: 63468

llvm-svn: 63467

function/call info.

llvm-svn: 63466

llvm-svn: 63464

llvm-svn: 63463

llvm-svn: 63462

nonfragile abi).

llvm-svn: 63461

to private extern (in objc2 nonfragile abi).

llvm-svn: 63460

llvm-svn: 63459

Complete (modulo bugs).

llvm-svn: 63458

(modulo bugs)

llvm-svn: 63457

couple of things that use it.

llvm-svn: 63456

in terms of where the type resides in the containing object. This is a
more clear embodiement of the spec & fixes a merging issue with
unions. Down to 3/1000 failures.

llvm-svn: 63455

llvm-svn: 63454

llvm-svn: 63453

llvm-svn: 63452

llvm-svn: 63451

sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.

Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.

llvm-svn: 63450

llvm-svn: 63449

llvm-svn: 63448

Turn on -flax-vector-conversions by default, issue a warning whenever one is done. Add a -fnolax-vector-conversions option. Fixes PR2862.

llvm-svn: 63447

llvm-svn: 63446

llvm-svn: 63445

argument.  Adjust all callers and overloaded versions.

llvm-svn: 63444

llvm-svn: 63443

llvm-svn: 63442

llvm-svn: 63441

llvm-svn: 63440

llvm-svn: 63439

computing in bytes not bits. We are now down to 22/1000 failures on
the return types tests, and 18 of those are gcc bugs I believe.

llvm-svn: 63438

llvm-svn: 63437

llvm-svn: 63436

error, since both C99 and C++ consider it an error. For reference, GCC
makes this a warning while G++ makes it an error.

llvm-svn: 63435

llvm-svn: 63434