class; they should just be completely opaque throughout IR gen now,
although I haven't really audited that.
Fix a bug apparently inherited from gcc-4.2 where we failed to null-check
member data pointers when performing derived-to-base or base-to-derived
conversions on them.
llvm-svn: 111789
Make CGT defer to the ABI on all member pointer types.
This requires giving CGT a handle to the ABI.
It's way easier to make that work if we avoid lazily creating the ABI.
Make it so.
llvm-svn: 111786
pointers. I find the resulting code to be substantially cleaner, and it
makes it very easy to use the same APIs for data member pointers (which I have
conscientiously avoided here), and it avoids a plethora of potential
inefficiencies due to excessive memory copying, but we'll have to see if it
actually works.
llvm-svn: 111776
duplication between the constant and non-constant paths in all of this.
Implement ARM ABI semantics for member pointer constants and conversion.
llvm-svn: 111772
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
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
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
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
- 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
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
which is a common idiom to improve PIC'ness of code using the addr of
label extension. This implementation is a gross hack, but the only other
alternative would be to teach evalutate about this horrid combination.
While GCC allows things like "&&foo - &&bar + 1", people don't use this
in practice. This implements PR5131.
llvm-svn: 83957
Issue reported on cfe-dev.
Also fixed the code to use isConstant to determine whether to generate a
constant global, to be consistent with CodeGenModule. This probably
needs to be refactored to deal with C++, though.
llvm-svn: 80131
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
llvm-svn: 77510
until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.
llvm-svn: 76193
Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.
llvm-svn: 74506
preprocessor and initialize it early in clang-cc. This
ensures that __has_builtin works in all modes, not just
when ASTContext is around.
llvm-svn: 73319
to allow us to support generation of deferred ctors/dtors.
It looks like codegen isn't emitting a call to the dtor in
member-functions.cpp:test2, but when it does, its body should
get emitted.
llvm-svn: 71594
Changed GenerateConstantString() to take an ObjCStringLiteral (instead of a std::string). While this isn't strictly necessary, it seems cleaner and allows us to cache to "containsNonAscii" if necessary (to avoid checking in both Sema and CodeGen).
llvm-svn: 68114
only occur for pointer types; they are also possible for integer types
now.
- No intended functionality change, IntExprEvaluate doesn't return
LValue results yet.
llvm-svn: 65066
IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.
This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.
llvm-svn: 64780
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.
Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.
Be a bit more careful about when we consider a function a "builtin" in
C++.
llvm-svn: 64561
represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.
The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.
llvm-svn: 63317
initializers.
- We now initialize unions properly when a member other than the
first is named by a designated initializer.
- We now provide proper semantic analysis and code generation for
GNU array-range designators *except* that side effects will occur
more than once. We warn about this.
llvm-svn: 63253
The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.
Known limitations:
- Designating a member of a union that isn't the first member may
result in bogus initialization (we warn about this)
- GNU array-range designators are not supported (we warn about this)
llvm-svn: 63242
information for declarations that were referenced via a qualified-id,
e.g., N::C::value. We keep track of the location of the start of the
nested-name-specifier. Note that the difference between
QualifiedDeclRefExpr and DeclRefExpr does have an effect on the
semantics of function calls in two ways:
1) The use of a qualified-id instead of an unqualified-id suppresses
argument-dependent lookup
2) If the name refers to a virtual function, the qualified-id
version will call the function determined statically while the
unqualified-id version will call the function determined dynamically
(by looking up the appropriate function in the vtable).
Neither of these features is implemented yet, but we do print out
qualified names for QualifiedDeclRefExprs as part of the AST printing.
llvm-svn: 61789
which can refer to static data members, enumerators, and member
functions as well as to non-static data members.
Implement correct lvalue computation for member references in C++.
Compute the result type of non-static data members of reference type properly.
llvm-svn: 61294
and separates lexical name lookup from qualified name lookup. In
particular:
* Make DeclContext the central data structure for storing and
looking up declarations within existing declarations, e.g., members
of structs/unions/classes, enumerators in C++0x enums, members of
C++ namespaces, and (later) members of Objective-C
interfaces/implementations. DeclContext uses a lazily-constructed
data structure optimized for fast lookup (array for small contexts,
hash table for larger contexts).
* Implement C++ qualified name lookup in terms of lookup into
DeclContext.
* Implement C++ unqualified name lookup in terms of
qualified+unqualified name lookup (since unqualified lookup is not
purely lexical in C++!)
* Limit the use of the chains of declarations stored in
IdentifierInfo to those names declared lexically.
* Eliminate CXXFieldDecl, collapsing its behavior into
FieldDecl. (FieldDecl is now a ScopedDecl).
* Make RecordDecl into a DeclContext and eliminates its
Members/NumMembers fields (since one can just iterate through the
DeclContext to get the fields).
llvm-svn: 60878
- Returns addr of constant for argument + '\0'.
- I couldn't think of a better name.
- Move appropriate users of GetAddrOfConstantString to this.
Rename getStringForStringLiteral to GetStringForStringLiteral.
Add GetAddrOfConstantStringFromLiteral
- This combines GetAddrOfConstantString and
GetStringForStringLiteral. This method can be, but is not yet, more
efficient.
Change GetAddrOfConstantString to not add terminating '\0'
- <rdar://problem/6140956>
llvm-svn: 54768
ObjCProtocolDecl directly.
Implement CodeGen support for forward protocol decls (no-ops are so
nice to implement).
Also moved CGObjCRuntime.h out of CodeGenModule.h
llvm-svn: 54709
Changed CGObjCRuntime::GenerateConstantString interface to take
std::string instead of char* and size.
Change ObjC functions which call on GenerateConstantString to bitcast
result to appropriate type.
llvm-svn: 54659
temporarily, I assumed GetAddrForConstantString literal was being
used consistently but it doesn't look like it is.
Factored out a CodeGenModule::getStringForStringLiteral which handles
extracting a std::string for the bytes of a StringLiteral, padded to
match the type.
Update EmitLValue to use getStringForStringLiteral, this was
previously not padding strings correctly. Good thing we only emit
strings in 4 different places!
llvm-svn: 54621
move getAsArrayType into ASTContext instead of being a method on type.
This is required because getAsArrayType(const AT), where AT is a typedef
for "int[10]" needs to return ArrayType(const int, 10).
Fixing this greatly simplifies getArrayDecayedType, which is a good sign.
llvm-svn: 54317
- No (intended) functionality change.
- Primary purpose is to clearly separate (lazy) construction of
globals that are a forward declaration or tentative definition from
those that are the final definition.
- Lazy construction is now encapsulated in
GetAddrOf{Function,GlobalVar} while final definitions are
constructed in EmitGlobal{Function,Var}Definition.
- External interface for dealing with globals is now limited to
EmitGlobal and GetAddrOf{Function,GlobalVar}.
- Also updated helper functions dealing with statics, annotations,
and ctors to be private.
llvm-svn: 54179
Anders Carlsson