Store inheritance paths after CastExprs instead of inside them.
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).

Also, smoosh the CastKind into the bitfield from Exp

Store inheritance paths after CastExprs instead of inside them.
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).

Also, smoosh the CastKind into the bitfield from Expr.

Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.

llvm-svn: 110507

show more ...

Fix crash initializing a bit-field with a non-constant in a place where we
try to evaluate the initializer as a constant.

llvm-svn: 108632

fix PR7564 a cast where the bitfield struct init code
wasn't handling array padding elements right.

llvm-svn: 107621

AppendBitField really can never fail, so return its return value.
Everyone knows that no bugs are ever possible with bitfields.

llvm-svn: 107620

use more efficient type comparison predicates.

llvm-svn: 106958

Don't try to explicitly zero out bit-fields.

llvm-svn: 105391

Fix for PR7040: Don't try to compute the LLVM type for a function where it
isn't possible to compute.

This patch is mostly refactoring; the key change is the addition of the code
starting with the c

Fix for PR7040: Don't try to compute the LLVM type for a function where it
isn't possible to compute.

This patch is mostly refactoring; the key change is the addition of the code
starting with the comment, "Check whether the function has a computable LLVM
signature." The solution here is essentially the same as the way the
vtable code handles such functions.

llvm-svn: 105151

show more ...

When null-initializing bases with data member pointers, don't assert on virtual bases. Just initialize them to null.

llvm-svn: 104868

Correctly initialize bases with member pointers. This should fix PR6441 but that test case is a bit weird and I'd like to investigate further before closing that bug.

llvm-svn: 104025

Move ContainsPointerToDataMember to CodeGenTypes. No functionality change.

llvm-svn: 103792

When computing the address of a virtual member function pointer, use the pointer width instead of hardcoding for 64-bit.

llvm-svn: 102921

Get rid of the old GetNonVirtualBaseClassOffset and change all call sites to use the new version.

llvm-svn: 102274

recommit r101568 to fix PR6766
as a side-effect, remove two FIXMEs now fixed

llvm-svn: 101726

Vtable -> VTable renames across the board.

llvm-svn: 101666

revert r101568, which miscompiles this testcase, distilled from ldecod:

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

fix PR6766: codegen of var initialized with wide char

llvm-svn: 101568

fix a bogus assertion exposed by a recent change: packing the
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 = g

fix a bogus assertion exposed by a recent change: packing the
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

show more ...

emit padding as undef values, take 2
merge also a few tests I had here for this feature, and FileCheck'ize one file

llvm-svn: 101535

Rework the ConstStructBuilder code to emit missing initializer
elements with explicit zero values instead of with tail padding.
On an example like this:

struct foo { int a; int b; };

struct foo foo

Rework the ConstStructBuilder code to emit missing initializer
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

show more ...

move a bunch of ConstStructBuilder methods out of line.

llvm-svn: 101152

fix PR6660/6168: emit padding as zeros instead of undef. Because
trailing fields may not be represented in initializer lists, they
are being handled as padding and those fields *must* be zero
init

fix PR6660/6168: emit padding as zeros instead of undef. Because
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

show more ...

IRGen: Move the auxiliary data structures tracking AST -> LLVM mappings out of CodeGenTypes, to per-record CGRecordLayout structures.
- I did a cursory check that this was perf neutral, FWIW.

llvm-

IRGen: Move the auxiliary data structures tracking AST -> LLVM mappings out of CodeGenTypes, to per-record CGRecordLayout structures.
- I did a cursory check that this was perf neutral, FWIW.

llvm-svn: 99978

show more ...

IRgen: Move CGRecordLayout to its own happy little file.

llvm-svn: 99945

Rename CGVtableInfo to CodeGenVTables in preparation of adding another VTableInfo class.

llvm-svn: 99250

really fix 6473 by handling weakref in constant expressions.

llvm-svn: 97750