2008-08-11 10:45:11 +08:00
|
|
|
//===----- CGObjCRuntime.h - Interface to ObjC Runtimes ---------*- C++ -*-===//
|
2008-03-01 16:50:34 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This provides an abstract class for Objective-C code generation. Concrete
|
|
|
|
// subclasses of this implement code generation for specific Objective-C
|
|
|
|
// runtime libraries.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:25:19 +08:00
|
|
|
#ifndef LLVM_CLANG_LIB_CODEGEN_CGOBJCRUNTIME_H
|
|
|
|
#define LLVM_CLANG_LIB_CODEGEN_CGOBJCRUNTIME_H
|
2008-11-01 09:53:16 +08:00
|
|
|
#include "CGBuilder.h"
|
2008-09-09 09:06:48 +08:00
|
|
|
#include "CGCall.h"
|
2008-11-01 09:53:16 +08:00
|
|
|
#include "CGValue.h"
|
2012-12-04 17:13:33 +08:00
|
|
|
#include "clang/AST/DeclObjC.h"
|
|
|
|
#include "clang/Basic/IdentifierTable.h" // Selector
|
2008-08-23 11:46:30 +08:00
|
|
|
|
2008-03-01 16:50:34 +08:00
|
|
|
namespace llvm {
|
|
|
|
class Constant;
|
2009-04-22 15:32:20 +08:00
|
|
|
class Function;
|
|
|
|
class Module;
|
|
|
|
class StructLayout;
|
2009-04-22 17:39:34 +08:00
|
|
|
class StructType;
|
2008-03-01 16:50:34 +08:00
|
|
|
class Type;
|
|
|
|
class Value;
|
|
|
|
}
|
|
|
|
|
|
|
|
namespace clang {
|
2008-09-09 09:06:48 +08:00
|
|
|
namespace CodeGen {
|
|
|
|
class CodeGenFunction;
|
|
|
|
}
|
2008-08-23 11:46:30 +08:00
|
|
|
|
2009-04-22 15:32:20 +08:00
|
|
|
class FieldDecl;
|
2008-09-09 18:04:29 +08:00
|
|
|
class ObjCAtTryStmt;
|
|
|
|
class ObjCAtThrowStmt;
|
2008-11-16 05:26:17 +08:00
|
|
|
class ObjCAtSynchronizedStmt;
|
2009-01-11 05:06:09 +08:00
|
|
|
class ObjCContainerDecl;
|
2008-08-16 06:20:32 +08:00
|
|
|
class ObjCCategoryImplDecl;
|
|
|
|
class ObjCImplementationDecl;
|
2008-08-16 08:25:02 +08:00
|
|
|
class ObjCInterfaceDecl;
|
2008-08-23 11:46:30 +08:00
|
|
|
class ObjCMessageExpr;
|
2008-08-16 06:20:32 +08:00
|
|
|
class ObjCMethodDecl;
|
2008-08-13 08:59:25 +08:00
|
|
|
class ObjCProtocolDecl;
|
2008-06-26 12:37:12 +08:00
|
|
|
class Selector;
|
2009-02-03 04:02:29 +08:00
|
|
|
class ObjCIvarDecl;
|
2009-04-01 00:53:37 +08:00
|
|
|
class ObjCStringLiteral;
|
2010-08-05 00:57:49 +08:00
|
|
|
class BlockDeclRefExpr;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2008-03-01 16:50:34 +08:00
|
|
|
namespace CodeGen {
|
2008-06-26 12:19:03 +08:00
|
|
|
class CodeGenModule;
|
2011-02-07 18:33:21 +08:00
|
|
|
class CGBlockInfo;
|
2008-03-01 16:50:34 +08:00
|
|
|
|
2009-05-16 15:57:57 +08:00
|
|
|
// FIXME: Several methods should be pure virtual but aren't to avoid the
|
|
|
|
// partially-implemented subclass breaking.
|
2008-06-01 22:13:53 +08:00
|
|
|
|
|
|
|
/// Implements runtime-specific code generation functions.
|
2008-03-01 16:50:34 +08:00
|
|
|
class CGObjCRuntime {
|
2010-04-06 05:36:35 +08:00
|
|
|
protected:
|
2012-02-17 11:33:10 +08:00
|
|
|
CodeGen::CodeGenModule &CGM;
|
|
|
|
CGObjCRuntime(CodeGen::CodeGenModule &CGM) : CGM(CGM) {}
|
|
|
|
|
2009-04-22 15:32:20 +08:00
|
|
|
// Utility functions for unified ivar access. These need to
|
|
|
|
// eventually be folded into other places (the structure layout
|
|
|
|
// code).
|
|
|
|
|
2009-04-22 17:39:34 +08:00
|
|
|
/// Compute an offset to the given ivar, suitable for passing to
|
|
|
|
/// EmitValueForIvarAtOffset. Note that the correct handling of
|
|
|
|
/// bit-fields is carefully coordinated by these two, use caution!
|
2009-05-03 20:57:56 +08:00
|
|
|
///
|
|
|
|
/// The latter overload is suitable for computing the offset of a
|
|
|
|
/// sythesized ivar.
|
2012-11-07 06:15:52 +08:00
|
|
|
uint64_t ComputeIvarBaseOffset(CodeGen::CodeGenModule &CGM,
|
|
|
|
const ObjCInterfaceDecl *OID,
|
|
|
|
const ObjCIvarDecl *Ivar);
|
|
|
|
uint64_t ComputeIvarBaseOffset(CodeGen::CodeGenModule &CGM,
|
|
|
|
const ObjCImplementationDecl *OID,
|
|
|
|
const ObjCIvarDecl *Ivar);
|
2009-04-22 15:32:20 +08:00
|
|
|
|
|
|
|
LValue EmitValueForIvarAtOffset(CodeGen::CodeGenFunction &CGF,
|
|
|
|
const ObjCInterfaceDecl *OID,
|
|
|
|
llvm::Value *BaseValue,
|
|
|
|
const ObjCIvarDecl *Ivar,
|
|
|
|
unsigned CVRQualifiers,
|
2009-09-09 23:08:12 +08:00
|
|
|
llvm::Value *Offset);
|
2011-03-25 19:57:33 +08:00
|
|
|
/// Emits a try / catch statement. This function is intended to be called by
|
|
|
|
/// subclasses, and provides a generic mechanism for generating these, which
|
2012-06-16 06:10:14 +08:00
|
|
|
/// should be usable by all runtimes. The caller must provide the functions
|
|
|
|
/// to call when entering and exiting a \@catch() block, and the function
|
|
|
|
/// used to rethrow exceptions. If the begin and end catch functions are
|
|
|
|
/// NULL, then the function assumes that the EH personality function provides
|
|
|
|
/// the thrown object directly.
|
2011-03-25 19:57:33 +08:00
|
|
|
void EmitTryCatchStmt(CodeGenFunction &CGF,
|
|
|
|
const ObjCAtTryStmt &S,
|
2011-05-24 06:33:28 +08:00
|
|
|
llvm::Constant *beginCatchFn,
|
|
|
|
llvm::Constant *endCatchFn,
|
|
|
|
llvm::Constant *exceptionRethrowFn);
|
2015-10-30 08:56:02 +08:00
|
|
|
|
|
|
|
void EmitInitOfCatchParam(CodeGenFunction &CGF, llvm::Value *exn,
|
|
|
|
const VarDecl *paramDecl);
|
|
|
|
|
2012-06-16 06:10:14 +08:00
|
|
|
/// Emits an \@synchronize() statement, using the \p syncEnterFn and
|
|
|
|
/// \p syncExitFn arguments as the functions called to lock and unlock
|
|
|
|
/// the object. This function can be called by subclasses that use
|
|
|
|
/// zero-cost exception handling.
|
2011-03-25 19:57:33 +08:00
|
|
|
void EmitAtSynchronizedStmt(CodeGenFunction &CGF,
|
|
|
|
const ObjCAtSynchronizedStmt &S,
|
|
|
|
llvm::Function *syncEnterFn,
|
|
|
|
llvm::Function *syncExitFn);
|
2008-08-12 00:50:21 +08:00
|
|
|
|
2008-03-01 16:50:34 +08:00
|
|
|
public:
|
|
|
|
virtual ~CGObjCRuntime();
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2008-03-31 07:03:07 +08:00
|
|
|
/// Generate the function required to register all Objective-C components in
|
|
|
|
/// this compilation unit with the runtime library.
|
2008-08-16 06:20:32 +08:00
|
|
|
virtual llvm::Function *ModuleInitFunction() = 0;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
/// Get a selector for the specified name and type values.
|
|
|
|
/// The result should have the LLVM type for ASTContext::getObjCSelType().
|
|
|
|
virtual llvm::Value *GetSelector(CodeGenFunction &CGF, Selector Sel) = 0;
|
|
|
|
|
|
|
|
/// Get the address of a selector for the specified name and type values.
|
|
|
|
/// This is a rarely-used language extension, but sadly it exists.
|
|
|
|
///
|
|
|
|
/// The result should have the LLVM type for a pointer to
|
2008-08-16 06:20:32 +08:00
|
|
|
/// ASTContext::getObjCSelType().
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
virtual Address GetAddrOfSelector(CodeGenFunction &CGF, Selector Sel) = 0;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
/// Get a typed selector.
|
2013-03-01 03:01:20 +08:00
|
|
|
virtual llvm::Value *GetSelector(CodeGenFunction &CGF,
|
2009-05-06 05:36:57 +08:00
|
|
|
const ObjCMethodDecl *Method) = 0;
|
|
|
|
|
2010-07-24 08:37:23 +08:00
|
|
|
/// Get the type constant to catch for the given ObjC pointer type.
|
|
|
|
/// This is used externally to implement catching ObjC types in C++.
|
|
|
|
/// Runtimes which don't support this should add the appropriate
|
|
|
|
/// error to Sema.
|
2011-06-24 03:00:08 +08:00
|
|
|
virtual llvm::Constant *GetEHType(QualType T) = 0;
|
2010-07-24 08:37:23 +08:00
|
|
|
|
2008-08-16 06:20:32 +08:00
|
|
|
/// Generate a constant string object.
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
virtual ConstantAddress GenerateConstantString(const StringLiteral *) = 0;
|
2012-03-07 04:05:56 +08:00
|
|
|
|
2008-06-01 22:13:53 +08:00
|
|
|
/// Generate a category. A category contains a list of methods (and
|
|
|
|
/// accompanying metadata) and a list of protocols.
|
2008-08-16 06:20:32 +08:00
|
|
|
virtual void GenerateCategory(const ObjCCategoryImplDecl *OCD) = 0;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2011-04-15 13:22:18 +08:00
|
|
|
/// Generate a class structure for this class.
|
2008-08-16 06:20:32 +08:00
|
|
|
virtual void GenerateClass(const ObjCImplementationDecl *OID) = 0;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2012-02-01 02:59:20 +08:00
|
|
|
/// Register an class alias.
|
|
|
|
virtual void RegisterAlias(const ObjCCompatibleAliasDecl *OAD) = 0;
|
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
/// Generate an Objective-C message send operation.
|
2009-09-17 12:01:22 +08:00
|
|
|
///
|
|
|
|
/// \param Method - The method being called, this may be null if synthesizing
|
|
|
|
/// a property setter or getter.
|
2009-09-09 23:08:12 +08:00
|
|
|
virtual CodeGen::RValue
|
2008-08-23 11:46:30 +08:00
|
|
|
GenerateMessageSend(CodeGen::CodeGenFunction &CGF,
|
2010-05-22 09:48:05 +08:00
|
|
|
ReturnValueSlot ReturnSlot,
|
2008-08-30 13:35:15 +08:00
|
|
|
QualType ResultType,
|
|
|
|
Selector Sel,
|
2008-08-25 16:19:24 +08:00
|
|
|
llvm::Value *Receiver,
|
2009-05-06 05:36:57 +08:00
|
|
|
const CallArgList &CallArgs,
|
2014-05-21 13:09:00 +08:00
|
|
|
const ObjCInterfaceDecl *Class = nullptr,
|
|
|
|
const ObjCMethodDecl *Method = nullptr) = 0;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2008-08-16 06:20:32 +08:00
|
|
|
/// Generate an Objective-C message send operation to the super
|
2008-08-25 16:19:24 +08:00
|
|
|
/// class initiated in a method for Class and with the given Self
|
|
|
|
/// object.
|
2009-09-17 12:01:22 +08:00
|
|
|
///
|
|
|
|
/// \param Method - The method being called, this may be null if synthesizing
|
|
|
|
/// a property setter or getter.
|
2008-08-23 11:46:30 +08:00
|
|
|
virtual CodeGen::RValue
|
|
|
|
GenerateMessageSendSuper(CodeGen::CodeGenFunction &CGF,
|
2010-05-22 09:48:05 +08:00
|
|
|
ReturnValueSlot ReturnSlot,
|
2008-08-30 13:35:15 +08:00
|
|
|
QualType ResultType,
|
|
|
|
Selector Sel,
|
2008-08-25 16:19:24 +08:00
|
|
|
const ObjCInterfaceDecl *Class,
|
2009-03-01 04:07:56 +08:00
|
|
|
bool isCategoryImpl,
|
2008-08-25 16:19:24 +08:00
|
|
|
llvm::Value *Self,
|
2008-08-30 11:02:31 +08:00
|
|
|
bool IsClassMessage,
|
2009-09-17 12:01:22 +08:00
|
|
|
const CallArgList &CallArgs,
|
2014-05-21 13:09:00 +08:00
|
|
|
const ObjCMethodDecl *Method = nullptr) = 0;
|
2008-08-12 13:08:18 +08:00
|
|
|
|
|
|
|
/// Emit the code to return the named protocol as an object, as in a
|
2012-06-11 14:19:40 +08:00
|
|
|
/// \@protocol expression.
|
2013-03-01 03:01:20 +08:00
|
|
|
virtual llvm::Value *GenerateProtocolRef(CodeGenFunction &CGF,
|
2008-08-16 06:20:32 +08:00
|
|
|
const ObjCProtocolDecl *OPD) = 0;
|
2008-08-12 13:08:18 +08:00
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
/// Generate the named protocol. Protocols contain method metadata but no
|
|
|
|
/// implementations.
|
2008-08-16 06:20:32 +08:00
|
|
|
virtual void GenerateProtocol(const ObjCProtocolDecl *OPD) = 0;
|
|
|
|
|
|
|
|
/// Generate a function preamble for a method with the specified
|
2009-09-09 23:08:12 +08:00
|
|
|
/// types.
|
2008-08-16 06:20:32 +08:00
|
|
|
|
2009-05-16 15:57:57 +08:00
|
|
|
// FIXME: Current this just generates the Function definition, but really this
|
|
|
|
// should also be generating the loads of the parameters, as the runtime
|
|
|
|
// should have full control over how parameters are passed.
|
2009-09-09 23:08:12 +08:00
|
|
|
virtual llvm::Function *GenerateMethod(const ObjCMethodDecl *OMD,
|
2009-01-11 05:06:09 +08:00
|
|
|
const ObjCContainerDecl *CD) = 0;
|
2008-08-13 08:59:25 +08:00
|
|
|
|
2008-09-24 11:38:44 +08:00
|
|
|
/// Return the runtime function for getting properties.
|
2009-03-23 05:03:39 +08:00
|
|
|
virtual llvm::Constant *GetPropertyGetFunction() = 0;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2008-09-24 11:38:44 +08:00
|
|
|
/// Return the runtime function for setting properties.
|
2009-03-23 05:03:39 +08:00
|
|
|
virtual llvm::Constant *GetPropertySetFunction() = 0;
|
2008-09-24 11:38:44 +08:00
|
|
|
|
2012-03-07 04:05:56 +08:00
|
|
|
/// Return the runtime function for optimized setting properties.
|
|
|
|
virtual llvm::Constant *GetOptimizedPropertySetFunction(bool atomic,
|
|
|
|
bool copy) = 0;
|
|
|
|
|
2010-12-27 06:13:16 +08:00
|
|
|
// API for atomic copying of qualified aggregates in getter.
|
|
|
|
virtual llvm::Constant *GetGetStructFunction() = 0;
|
|
|
|
// API for atomic copying of qualified aggregates in setter.
|
|
|
|
virtual llvm::Constant *GetSetStructFunction() = 0;
|
2012-12-18 02:54:24 +08:00
|
|
|
/// API for atomic copying of qualified aggregates with non-trivial copy
|
|
|
|
/// assignment (c++) in setter.
|
|
|
|
virtual llvm::Constant *GetCppAtomicObjectSetFunction() = 0;
|
|
|
|
/// API for atomic copying of qualified aggregates with non-trivial copy
|
|
|
|
/// assignment (c++) in getter.
|
|
|
|
virtual llvm::Constant *GetCppAtomicObjectGetFunction() = 0;
|
2010-04-13 02:18:10 +08:00
|
|
|
|
2008-08-16 08:25:02 +08:00
|
|
|
/// GetClass - Return a reference to the class for the given
|
|
|
|
/// interface decl.
|
2013-03-01 03:01:20 +08:00
|
|
|
virtual llvm::Value *GetClass(CodeGenFunction &CGF,
|
2008-08-16 08:25:02 +08:00
|
|
|
const ObjCInterfaceDecl *OID) = 0;
|
2011-06-16 07:02:42 +08:00
|
|
|
|
|
|
|
|
2013-03-01 03:01:20 +08:00
|
|
|
virtual llvm::Value *EmitNSAutoreleasePoolClassRef(CodeGenFunction &CGF) {
|
2011-09-23 13:06:16 +08:00
|
|
|
llvm_unreachable("autoreleasepool unsupported in this ABI");
|
2011-06-16 07:02:42 +08:00
|
|
|
}
|
|
|
|
|
2008-08-31 12:05:03 +08:00
|
|
|
/// EnumerationMutationFunction - Return the function that's called by the
|
|
|
|
/// compiler when a mutation is detected during foreach iteration.
|
2009-03-23 05:03:39 +08:00
|
|
|
virtual llvm::Constant *EnumerationMutationFunction() = 0;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2010-07-06 09:34:17 +08:00
|
|
|
virtual void EmitSynchronizedStmt(CodeGen::CodeGenFunction &CGF,
|
|
|
|
const ObjCAtSynchronizedStmt &S) = 0;
|
|
|
|
virtual void EmitTryStmt(CodeGen::CodeGenFunction &CGF,
|
|
|
|
const ObjCAtTryStmt &S) = 0;
|
2008-09-09 18:04:29 +08:00
|
|
|
virtual void EmitThrowStmt(CodeGen::CodeGenFunction &CGF,
|
2013-01-11 03:02:56 +08:00
|
|
|
const ObjCAtThrowStmt &S,
|
|
|
|
bool ClearInsertionPoint=true) = 0;
|
2009-04-21 08:49:20 +08:00
|
|
|
virtual llvm::Value *EmitObjCWeakRead(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address AddrWeakObj) = 0;
|
2008-11-19 06:37:34 +08:00
|
|
|
virtual void EmitObjCWeakAssign(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *src, Address dest) = 0;
|
2008-11-19 08:59:10 +08:00
|
|
|
virtual void EmitObjCGlobalAssign(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *src, Address dest,
|
2010-07-21 04:30:03 +08:00
|
|
|
bool threadlocal=false) = 0;
|
2008-11-21 03:23:36 +08:00
|
|
|
virtual void EmitObjCIvarAssign(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *src, Address dest,
|
2009-09-25 06:25:38 +08:00
|
|
|
llvm::Value *ivarOffset) = 0;
|
2008-11-19 08:59:10 +08:00
|
|
|
virtual void EmitObjCStrongCastAssign(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
llvm::Value *src, Address dest) = 0;
|
2009-09-09 23:08:12 +08:00
|
|
|
|
2009-02-04 03:03:09 +08:00
|
|
|
virtual LValue EmitObjCValueForIvar(CodeGen::CodeGenFunction &CGF,
|
|
|
|
QualType ObjectTy,
|
|
|
|
llvm::Value *BaseValue,
|
|
|
|
const ObjCIvarDecl *Ivar,
|
|
|
|
unsigned CVRQualifiers) = 0;
|
2009-02-11 03:02:04 +08:00
|
|
|
virtual llvm::Value *EmitIvarOffset(CodeGen::CodeGenFunction &CGF,
|
2009-04-22 13:08:15 +08:00
|
|
|
const ObjCInterfaceDecl *Interface,
|
2009-02-11 03:02:04 +08:00
|
|
|
const ObjCIvarDecl *Ivar) = 0;
|
2009-07-08 09:18:33 +08:00
|
|
|
virtual void EmitGCMemmoveCollectable(CodeGen::CodeGenFunction &CGF,
|
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an
alignment. Introduce APIs on CGBuilderTy to work with Address
values. Change core APIs on CGF/CGM to traffic in Address where
appropriate. Require alignments to be non-zero. Update a ton
of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment
helper function to CGF and made use of it in a number of places in
the expression emitter.
The end result is that we should now be significantly more correct
when performing operations on objects that are locally known to
be under-aligned. Since alignment is not reliably tracked in the
type system, there are inherent limits to this, but at least we
are no longer confused by standard operations like derived-to-base
conversions and array-to-pointer decay. I've also fixed a large
number of bugs where we were applying the complete-object alignment
to a pointer instead of the non-virtual alignment, although most of
these were hidden by the very conservative approach we took with
member alignment.
Also, because IRGen now reliably asserts on zero alignments, we
should no longer be subject to an absurd but frustrating recurring
bug where an incomplete type would report a zero alignment and then
we'd naively do a alignmentAtOffset on it and emit code using an
alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment
attributes in the presence of over-alignment. In particular,
field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing
code-generation pattern in order to more effectively use
the Address APIs. For the most part, this seems to be a strict
improvement, like doing pointer arithmetic with GEPs instead of
ptrtoint. That said, I've tried very hard to not change semantics,
but it is likely that I've failed in a few places, for which I
apologize.
ABIArgInfo now always carries the assumed alignment of indirect and
indirect byval arguments. In order to cut down on what was already
a dauntingly large patch, I changed the code to never set align
attributes in the IR on non-byval indirect arguments. That is,
we still generate code which assumes that indirect arguments have
the given alignment, but we don't express this information to the
backend except where it's semantically required (i.e. on byvals).
This is likely a minor regression for those targets that did provide
this information, but it'll be trivial to add it back in a later
patch.
I partially punted on applying this work to CGBuiltin. Please
do not add more uses of the CreateDefaultAligned{Load,Store}
APIs; they will be going away eventually.
llvm-svn: 246985
2015-09-08 16:05:57 +08:00
|
|
|
Address DestPtr,
|
|
|
|
Address SrcPtr,
|
2010-06-16 06:44:06 +08:00
|
|
|
llvm::Value *Size) = 0;
|
2011-02-07 18:33:21 +08:00
|
|
|
virtual llvm::Constant *BuildGCBlockLayout(CodeGen::CodeGenModule &CGM,
|
|
|
|
const CodeGen::CGBlockInfo &blockInfo) = 0;
|
2012-10-28 05:10:38 +08:00
|
|
|
virtual llvm::Constant *BuildRCBlockLayout(CodeGen::CodeGenModule &CGM,
|
|
|
|
const CodeGen::CGBlockInfo &blockInfo) = 0;
|
2015-12-22 04:21:15 +08:00
|
|
|
|
|
|
|
/// Returns an i8* which points to the byref layout information.
|
2012-11-15 01:15:51 +08:00
|
|
|
virtual llvm::Constant *BuildByrefLayout(CodeGen::CodeGenModule &CGM,
|
|
|
|
QualType T) = 0;
|
2015-12-22 04:21:15 +08:00
|
|
|
|
2016-02-13 21:42:54 +08:00
|
|
|
virtual llvm::GlobalVariable *GetClassGlobal(StringRef Name,
|
2014-02-27 06:25:45 +08:00
|
|
|
bool Weak = false) = 0;
|
2012-02-17 11:33:10 +08:00
|
|
|
|
|
|
|
struct MessageSendInfo {
|
|
|
|
const CGFunctionInfo &CallInfo;
|
|
|
|
llvm::PointerType *MessengerType;
|
|
|
|
|
|
|
|
MessageSendInfo(const CGFunctionInfo &callInfo,
|
|
|
|
llvm::PointerType *messengerType)
|
|
|
|
: CallInfo(callInfo), MessengerType(messengerType) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
MessageSendInfo getMessageSendInfo(const ObjCMethodDecl *method,
|
|
|
|
QualType resultType,
|
|
|
|
CallArgList &callArgs);
|
2012-11-07 07:40:48 +08:00
|
|
|
|
|
|
|
// FIXME: This probably shouldn't be here, but the code to compute
|
|
|
|
// it is here.
|
|
|
|
unsigned ComputeBitfieldBitOffset(CodeGen::CodeGenModule &CGM,
|
|
|
|
const ObjCInterfaceDecl *ID,
|
|
|
|
const ObjCIvarDecl *Ivar);
|
2008-03-01 16:50:34 +08:00
|
|
|
};
|
|
|
|
|
2009-09-09 23:08:12 +08:00
|
|
|
/// Creates an instance of an Objective-C runtime class.
|
2008-03-31 07:03:07 +08:00
|
|
|
//TODO: This should include some way of selecting which runtime to target.
|
2008-08-11 10:45:11 +08:00
|
|
|
CGObjCRuntime *CreateGNUObjCRuntime(CodeGenModule &CGM);
|
|
|
|
CGObjCRuntime *CreateMacObjCRuntime(CodeGenModule &CGM);
|
2015-06-23 07:07:51 +08:00
|
|
|
}
|
|
|
|
}
|
2008-03-01 16:50:34 +08:00
|
|
|
#endif
|