llvm-svn: 101368

llvm-svn: 101366

llvm-svn: 101365

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

-fixit-at specified a particular fixit to fix, or the -o flag was used.

llvm-svn: 101359

llvm-svn: 101358

llvm-svn: 101357

 - Used to determine whether the alignment of the type in a bit-field is
   respected when laying out structures. The default is true, targets can
   override this as needed.

 - This is designed to correspond to the PCC_BITFIELD_TYPE_MATTERS macro in
   gcc. The AST/Sema implementation only affects one line, unless I have
   forgotten something. I'd appreciate further review.

 - IRgen still needs to be updated to fully support this (which is effectively
   PR5591).

llvm-svn: 101356

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

 - Note that this is a behavior change, previously -mllvm at the driver level forwarded to clang -cc1. The driver does a little magic to make sure that '-mllvm -disable-llvm-optzns' works correctly, but other users will need to be updated to use -Xclang.

llvm-svn: 101354

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

IRgen: Change CGBitFieldInfo to take the AccessInfo as constructor arguments, it is now an immutable object.

Also, add some checking of various invariants that should hold on the CGBitFieldInfo access.

llvm-svn: 101345

llvm-svn: 101344

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: 101341

llvm-svn: 101340

IRgen: (Reapply 101222, with fixes) Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.
 - Sadly, this doesn't seem to give any .ll size win so far. It is possible to make this routine significantly smarter & avoid various shifting, masking, and zext/sext, but I'm not really convinced it is worth it. It is tricky, and this is really instcombine's job.

 - No intended functionality change; the test case is just to increase coverage & serves as a demo file, it worked before this commit.

The new fixes from r101222 are:

 1. The shift to the target position needs to occur after the value is extended to the correct size. This broke Clang bootstrap, among other things no doubt.

 2. Swap the order of arguments to OR, to get a tad more constant folding.

llvm-svn: 101339

llvm-svn: 101338

llvm-svn: 101337

characters long.

llvm-svn: 101336

llvm-svn: 101335

llvm-svn: 101334

Stop multiplying constant by 8 accordingly in the header and change
intrinsic definition for what types we expect.

Add to existing palignr test to check that we're emitting the correct things.

llvm-svn: 101332

patterns to handle the lowering.

llvm-svn: 101331

llvm-svn: 101330

llvm-svn: 101329

a crash in InitListExpr's ctor.

llvm-svn: 101328

llvm-svn: 101327

containing the time taken for the code completion to be sent to a designated server
(which is specified using a compile-time -D flag).

llvm-svn: 101326

llvm-svn: 101325

llvm-svn: 101317

that have reference or const scalar members, since those members can
never be initializer or modified. Fixes <rdar://problem/7804350>.

llvm-svn: 101316

llvm-svn: 101315

llvm-svn: 101314

The commit "Adding IPSCCP and Internalize passes to the C-bindings" introduced
new dependencies for IPO. Add these to the CMAKE build as otherwise the
BUILD_SHARED_LIBS=1 build fails.

llvm-svn: 101313

ResolveAddressOfOverloadedFunction when asked to complain. Previously,
we had some weird handshake where ResolveAddressOfOverloadedFunction
expected its caller to handle some of the diagnostics but not others,
and yet there was no way for the caller to know which case we were
in. Eliminate this madness, fixing <rdar://problem/7765884>.

llvm-svn: 101312

llvm-svn: 101311

function checks whether we have a valid submode for VLDM/VSTM (must be either
"ia" or "db") before calling ARM_AM::getAM5Opc(AMSubMode, unsigned char).

llvm-svn: 101306