llvm-svn: 101376

llvm-svn: 101371

llvm-svn: 101368

of the operand array

the motivation for this patch are laid out in my mail to llvm-commits:
more efficient access to operands and callee, faster callgraph-construction,
smaller compiler binary

llvm-svn: 101364

tokenfactor in between the load/store.  This allows us to 
optimize test7 into:

_test7:                                 ## @test7
## BB#0:                                ## %entry
	movl	(%rdx), %eax
                                        ## kill: SIL<def> ESI<kill>
	movb	%sil, 5(%rdi)
	ret

instead of:

_test7:                                 ## @test7
## BB#0:                                ## %entry
	movl	4(%esp), %ecx
	movl	$-65281, %eax           ## imm = 0xFFFFFFFFFFFF00FF
	andl	4(%ecx), %eax
	movzbl	8(%esp), %edx
	shll	$8, %edx
	addl	%eax, %edx
	movl	12(%esp), %eax
	movl	(%eax), %eax
	movl	%edx, 4(%ecx)
	ret

llvm-svn: 101355

This doesn't occur much at all, it only seems to formed in the case
when the trunc optimization kicks in due to phase ordering.  In that
case it is saves a few bytes on x86-32.

llvm-svn: 101350

and.  This happens with the store->load narrowing stuff.

llvm-svn: 101348

a load/or/and/store sequence into a narrower store when it is
safe.  Daniel tells me that clang will start producing this sort
of thing with bitfields, and this does  trigger a few dozen times
on 176.gcc produced by llvm-gcc even now.

This compiles code like CodeGen/X86/2009-05-28-DAGCombineCrash.ll 
into:

        movl    %eax, 36(%rdi)

instead of:

        movl    $4294967295, %eax       ## imm = 0xFFFFFFFF
        andq    32(%rdi), %rax
        shlq    $32, %rcx
        addq    %rax, %rcx
        movq    %rcx, 32(%rdi)

and each of the testcases into a single store.  Each of them used
to compile into craziness like this:

_test4:
	movl	$65535, %eax            ## imm = 0xFFFF
	andl	(%rdi), %eax
	shll	$16, %esi
	addl	%eax, %esi
	movl	%esi, (%rdi)
	ret

llvm-svn: 101343

llvm-svn: 101342

llvm-svn: 101334

llvm-svn: 101330

llvm-svn: 101325

llvm-svn: 101317

llvm-svn: 101315

llvm-svn: 101314

llvm-svn: 101276

llvm-svn: 101275

a bunch of stuff to support it.

llvm-svn: 101273

llvm-svn: 101272

llvm-svn: 101269

SelectionDAGBuilder. FunctionLoweringInfo isn't an ideal place for
them to live, but it's better than SelectionDAGBuilder for now.

llvm-svn: 101267

llvm-svn: 101266

llvm-svn: 101264

llvm-svn: 101263

don't need it.

llvm-svn: 101262

drop the redundant #ifndef NDEBUG.

llvm-svn: 101261

llvm-svn: 101260

SelectionDAGISel.

llvm-svn: 101258

llvm-svn: 101256

llvm-svn: 101255

llvm-svn: 101254

SelectionDAGISel::runOnMachineFunction into FunctionLowering.

llvm-svn: 101252

llvm-svn: 101251

llvm-svn: 101210

llvm-svn: 101206

llvm-svn: 101202

llvm-svn: 101183

llvm-svn: 101171

llvm-svn: 101170

Expand postra machine licm's capability a little more. If an instruction's register operands are all loop invariants, then it's safe to hoist it.

llvm-svn: 101167