| Age | Commit message (Collapse) | Author |
|---|
|
llvm-svn: 106958
|
|
llvm-svn: 105391
|
|
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
|
|
virtual bases. Just initialize them to null.
llvm-svn: 104868
|
|
that test case is a bit weird and I'd like to investigate further before closing that bug.
llvm-svn: 104025
|
|
llvm-svn: 103792
|
|
pointer width instead of hardcoding for 64-bit.
llvm-svn: 102921
|
|
use the new version.
llvm-svn: 102274
|
|
as a side-effect, remove two FIXMEs now fixed
llvm-svn: 101726
|
|
llvm-svn: 101666
|
|
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
|
|
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
|
|
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
|
|
llvm-svn: 101152
|
|
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
|
|
of CodeGenTypes, to per-record CGRecordLayout structures.
- I did a cursory check that this was perf neutral, FWIW.
llvm-svn: 99978
|
|
llvm-svn: 99945
|
|
VTableInfo class.
llvm-svn: 99250
|
|
llvm-svn: 97750
|
|
llvm-svn: 95812
|
|
pointer. Fixes PR6258.
llvm-svn: 95524
|
|
llvm-svn: 95400
|
|
llvm-svn: 95389
|
|
llvm-svn: 95375
|
|
a constant (even if it has a trivial constructor).
llvm-svn: 95363
|
|
llvm-svn: 95305
|
|
working code, for no apparent reason.
llvm-svn: 95244
|
|
- Don't use GlobalAliases with non-0 GEPs (GNU runtime) - this was unsupported and LLVM will be generating errors if you do it soon. This also simplifies the code generated by the GNU runtime a bit.
- Make GetSelector() return a constant (GNU runtime), not a load of a store of a constant.
- Recognise @selector() expressions as valid static initialisers (as GCC does).
- Add methods to GCObjCRuntime to emit selectors as constants (needed for using @selector() expressions as constants. These need implementing for the Mac runtimes - I couldn't figure out how to do this, they seem to require a load.
- Store an ObjCMethodDecl in an ObjCSelectorExpr so that we can get at the type information for the selector. This is needed for generating typed selectors from @selector() expressions (as GCC does). Ideally, this information should be stored in the Selector, but that would be an invasive change. We should eventually add checks for common uses of @selector() expressions. Possibly adding an attribute that can be applied to method args providing the types of a selector so, for example, you'd do something like this:
- (id)performSelector: __attribute__((selector_types(id, SEL, id)))(SEL)
withObject: (id)object;
Then, any @selector() expressions passed to the method will be check to ensure that it conforms to this signature. We do this at run time on the GNU runtime already, but it would be nice to do it at compile time on all runtimes.
- Made @selector() expressions emit type info if available and the runtime supports it.
Someone more familiar with the Mac runtime needs to implement the GetConstantSelector() function in CGObjCMac. This currently just assert()s.
llvm-svn: 95189
|
|
unused variable warning.
llvm-svn: 95085
|
|
Eliminates a lot of spurious global initializers, fixing PR6205.
llvm-svn: 95077
|
|
llvm-svn: 95066
|
|
CGExprConstant. Fixes PR5674.
llvm-svn: 95063
|
|
llvm-svn: 94938
|
|
constant Objective-C strings.
llvm-svn: 94274
|
|
the LValue-related methods of APValue out of line to avoid header file leaching.
llvm-svn: 93512
|
|
function is virtual. Fixes PR5940.
llvm-svn: 92680
|
|
llvm-svn: 92432
|
|
- This fixes 2003-05-21-BitfieldHandling.
llvm-svn: 90876
|
|
llvm-svn: 90044
|
|
llvm-svn: 90017
|
|
llvm-svn: 89569
|
|
legitimately has side-effects (and needs to be generated as a non-constant).
llvm-svn: 88767
|
|
local variable.
llvm-svn: 88766
|
|
llvm-svn: 88696
|
|
llvm-svn: 86256
|
|
this enables constant compaction optimizations.
llvm-svn: 85504
|
|
using the new LLVM support for this. This is temporarily hiding
behind horrible and ugly #ifdefs until the time when the optimizer
is stable (hopefully a week or so). Until then, lets make it "opt in" :)
llvm-svn: 85446
|
|
qualified reference to a declaration that is not a non-static data
member or non-static member function, e.g.,
namespace N { int i; }
int j = N::i;
Instead, extend DeclRefExpr to optionally store the qualifier. Most
clients won't see or care about the difference (since
QualifierDeclRefExpr inherited DeclRefExpr). However, this reduces the
number of top-level expression types that clients need to cope with,
brings the implementation of DeclRefExpr into line with MemberExpr,
and simplifies and unifies our handling of declaration references.
Extended DeclRefExpr to (optionally) store explicitly-specified
template arguments. This occurs when naming a declaration via a
template-id (which will be stored in a TemplateIdRefExpr) that,
following template argument deduction and (possibly) overload
resolution, is replaced with a DeclRefExpr that refers to a template
specialization but maintains the template arguments as written.
llvm-svn: 84962
|
