llvm-svn: 112411

This leads to much simpler code.

llvm-svn: 112410

llvm-svn: 112409

llvm-svn: 112408

getUniqueExitBlocks instead of getExitBlocks and a manual
set to eliminate dupes.

llvm-svn: 112405

llvm-svn: 112404

llvm-svn: 112403

of the sets is volatile.  We were dropping the volatile bit of the
merged in set, leading (luckily) to assertions in cases like 
PR7535.  I cannot produce a testcase that repros with opt, but this
is obviously correct.

llvm-svn: 112402

llvm-svn: 112401

llvm-svn: 112400

- Create T2I_bin_sw_irs to be like T2I_bin_w_irs, but that it sets the S bit.

llvm-svn: 112399

llvm-svn: 112398

llvm-svn: 112397

llvm-svn: 112396

llvm-svn: 112395

llvm-svn: 112394

it sets the CPSR register.

llvm-svn: 112393

llvm-svn: 112392

Patch by Francois Pichet!

llvm-svn: 112391

properly account for the possibility that certain opaque types
might be more qualified than they appear.  Fixes PR7708.

llvm-svn: 112390

This is test for git svn dcommit

llvm-svn: 112389

llvm-svn: 112388

times.  This patch causes llc and llvm-mc (which both default to
verbose-asm) to print out comments after a few common shuffle 
instructions which indicates the shuffle mask, e.g.:

	insertps	$113, %xmm3, %xmm0     ## xmm0 = zero,xmm0[1,2],xmm3[1]
	unpcklps	%xmm1, %xmm0    ## xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
	pshufd	$1, %xmm1, %xmm1        ## xmm1 = xmm1[1,0,0,0]

This is carefully factored to keep the information extraction (of the
shuffle mask) separate from the printing logic.  I plan to move the
extraction part out somewhere else at some point for other parts of
the x86 backend that want to introspect on the behavior of shuffles.

llvm-svn: 112387

llvm-svn: 112386

llvm-svn: 112385

And it is my 1st test commit.

llvm-svn: 112384

kind.  Fixes PR7252.

llvm-svn: 112383

llvm-svn: 112382

llvm-svn: 112381

llvm-svn: 112380

insertp[sd] $0, which is a noop.  Before:

_f32:                                   ## @f32
	pshufd	$1, %xmm1, %xmm2
	pshufd	$1, %xmm0, %xmm3
	addss	%xmm2, %xmm3
	addss	%xmm1, %xmm0
                                        ## kill: XMM0<def> XMM0<kill> XMM0<def>
	insertps	$0, %xmm0, %xmm0
	insertps	$16, %xmm3, %xmm0
	ret

after:

_f32:                                   ## @f32
	movdqa	%xmm0, %xmm2
	addss	%xmm1, %xmm2
	pshufd	$1, %xmm1, %xmm1
	pshufd	$1, %xmm0, %xmm3
	addss	%xmm1, %xmm3
	movdqa	%xmm2, %xmm0
	insertps	$16, %xmm3, %xmm0
	ret

The extra movs are due to a random (poor) scheduling decision.

llvm-svn: 112379

when the top elements of a vector are undefined.  This happens all
the time for X86-64 ABI stuff because only the low 2 elements of
a 4 element vector are defined.  For example, on:

_Complex float f32(_Complex float A, _Complex float B) {
  return A+B;
}

We used to produce (with SSE2, SSE4.1+ uses insertps):

_f32:                                   ## @f32
	movdqa	%xmm0, %xmm2
	addss	%xmm1, %xmm2
	pshufd	$16, %xmm2, %xmm2
	pshufd	$1, %xmm1, %xmm1
	pshufd	$1, %xmm0, %xmm0
	addss	%xmm1, %xmm0
	pshufd	$16, %xmm0, %xmm1
	movdqa	%xmm2, %xmm0
	unpcklps	%xmm1, %xmm0
	ret

We now produce:

_f32:                                   ## @f32
	movdqa	%xmm0, %xmm2
	addss	%xmm1, %xmm2
	pshufd	$1, %xmm1, %xmm1
	pshufd	$1, %xmm0, %xmm3
	addss	%xmm1, %xmm3
	movaps	%xmm2, %xmm0
	unpcklps	%xmm3, %xmm0
	ret

This implements rdar://8368414

llvm-svn: 112378

a new EltStride variable instead of reusing NumElems variable
for a non-obvious purpose.  No functionality change.

llvm-svn: 112377

According to the Microsoft documentation here:
http://msdn.microsoft.com/en-us/library/ms724284%28VS.85%29.aspx

this cast used in lib/System/Win32/Path.inc:

__int64 ft = *reinterpret_cast<__int64*>(&fi.ftLastWriteTime);

should not be done.  The documentation says: "Do not cast a pointer to a
FILETIME structure to either a ULARGE_INTEGER* or __int64* value because
it can cause alignment faults on 64-bit Windows."

llvm-svn: 112376

and hasn't kept up with ToT.  Approved by Anton.

llvm-svn: 112375

llvm-svn: 112374

llvm-svn: 112373

llvm-svn: 112372

llvm-svn: 112370

this is still failing, need to come up with a fix
(but we are in good company as the first gcc version
 pass this test will be v4.6)

llvm-svn: 112369