incomplete type.  Fixes PR6911.

llvm-svn: 102473

input and output types when the smaller value isn't mentioned in the
asm string.  Extend this support from integers to also allowing 
fp values to be mismatched (if not mentioned in the asm string).

llvm-svn: 102188

llvm-svn: 102182

variants.  This fixes neon inline asm which my patch for PR6780 broke.

llvm-svn: 102181

 - This fixes the last known ABI issues with ARM/APCS.

 - I've run the first 1k ABITests with '--no-unsigned --no-vector --no-complex'
   on {armv6, armv7} x {-mno-thumb, -mthumb}, and the first 10k tests for armv7
   -mthumb, for both function return types and single argument calls. These all
   pass now (they failed horribly before without --no-bitfield).

llvm-svn: 102070

immediately narrowed the access size. Fix this (and previous case) by just
choosing a better access size up-front.

llvm-svn: 102068

we have to narrow the access side immediately (can happen with packed,
-fno-bitfield-type-align).

llvm-svn: 102067

llvm-svn: 102046

IRgen: Rewrite bit-field access policy to not access data beyond the bounds of the structure, which we also now verify as part of the post-layout consistency checks.
 - This fixes some pedantic bugs with packed structures, as well as major problems with -fno-bitfield-type-align.

 - Fixes PR5591, PR5567, and all known -fno-bitfield-type-align issues.

 - Review appreciated.

llvm-svn: 102045

exceeds the minimum ABI alignment.

llvm-svn: 102019

llvm-svn: 102018

llvm-svn: 102016

matches how we currently handle structs, and this correctly handles
-fno-bitfield-type-align.

llvm-svn: 101918

This mirror's Dan's patch for llvm-gcc in r97989, and
fixes the miscompilation in PR6525.  There is some contention
over whether this is the right thing to do, but it is the
conservative answer and demonstrably fixes a miscompilation.

llvm-svn: 101877

as a side-effect, remove two FIXMEs now fixed

llvm-svn: 101726

llvm-svn: 101678

void exit_picture()
{
  char yuv_types[4][6]= {"4:0:0","4:2:0","4:2:2","4:4:4"};
  foo(yuv_types);
}

llvm-svn: 101623

llvm-svn: 101568

this follows from C99 6.7.8p10: if it is a union, the first named member is initialized

llvm-svn: 101539

struct may cause it to shrink more than one byte.  Before
my recent changes we compiled the new test into:

%0 = type { [6 x i8] }
@x = global %0 { [6 x i8] undef }, align 2        ; <%0*> [#uses=0]

which is obviously bogus.  Now we compile it into:

%0 = type <{ i32, i8, i8 }>
@x = global %0 zeroinitializer, align 2           ; <%0*> [#uses=0]

Where the last byte only is tail padding.

llvm-svn: 101536

merge also a few tests I had here for this feature, and FileCheck'ize one file

llvm-svn: 101535

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

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

Anton Yartsev!

llvm-svn: 101281

Speculatively revert "IRgen: Move EmitStoreThroughBitfieldLValue to use new CGBitfieldInfo::AccessInfo decomposition, instead of computing the access policy itself.", I think it might be breaking bootstrap.

llvm-svn: 101235

IRgen: 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.

llvm-svn: 101222

llvm-svn: 101215

elements with explicit zero values instead of with tail padding.
On an example like this:

struct foo { int a; int b; };

struct foo fooarray[] = {
    {1, 2},
    {4},
};

We now lay this out as:

@fooarray = global [2 x %struct.foo] [%struct.foo { i32 1, i32 2 }, %struct.foo { i32 4, i32 0 }]

instead of as:

@fooarray = global %0 <{ %struct.foo { i32 1, i32 2 }, %1 { i32 4, [4 x i8] zeroinitializer } }>

Preserving both the struct type of the second element, but also the array type of the entire thing.

llvm-svn: 101155

trailing fields may not be represented in initializer lists, they
are being handled as padding and those fields *must* be zero 
initialized.

llvm-svn: 101067

llvm-svn: 100962

llvm-svn: 100938

to the intrinsic, even when math-errno is off.

Fixes rdar://problem/7828230 by falling back on the library function.

llvm-svn: 100613

that the integrated assembler is working.

llvm-svn: 100545

llvm-svn: 100449

Reapply patch for adding support for address spaces and added a isVolatile field to memcpy, memmove, and memset.

llvm-svn: 100305

llvm-svn: 100236

llvm-svn: 100235

llvm-svn: 100200

Reapply patch for adding support for address spaces and added a isVolatile field to memcpy, memmove, and memset. 

llvm-svn: 100193

llvm-svn: 99962