1 //===---- TargetInfo.h - Encapsulate target details -------------*- C++ -*-===// 2 // 3 // The LLVM Compiler Infrastructure 4 // 5 // This file is distributed under the University of Illinois Open Source 6 // License. See LICENSE.TXT for details. 7 // 8 //===----------------------------------------------------------------------===// 9 // 10 // These classes wrap the information about a call or function 11 // definition used to handle ABI compliancy. 12 // 13 //===----------------------------------------------------------------------===// 14 15 #ifndef CLANG_CODEGEN_TARGETINFO_H 16 #define CLANG_CODEGEN_TARGETINFO_H 17 18 #include "clang/Basic/LLVM.h" 19 #include "clang/AST/Type.h" 20 #include "llvm/ADT/StringRef.h" 21 22 namespace llvm { 23 class GlobalValue; 24 class Type; 25 class Value; 26 } 27 28 namespace clang { 29 class ABIInfo; 30 class Decl; 31 32 namespace CodeGen { 33 class CodeGenModule; 34 class CodeGenFunction; 35 } 36 37 /// TargetCodeGenInfo - This class organizes various target-specific 38 /// codegeneration issues, like target-specific attributes, builtins and so 39 /// on. 40 class TargetCodeGenInfo { 41 ABIInfo *Info; 42 public: 43 // WARNING: Acquires the ownership of ABIInfo. 44 TargetCodeGenInfo(ABIInfo *info = 0):Info(info) { } 45 virtual ~TargetCodeGenInfo(); 46 47 /// getABIInfo() - Returns ABI info helper for the target. 48 const ABIInfo& getABIInfo() const { return *Info; } 49 50 /// SetTargetAttributes - Provides a convenient hook to handle extra 51 /// target-specific attributes for the given global. 52 virtual void SetTargetAttributes(const Decl *D, llvm::GlobalValue *GV, 53 CodeGen::CodeGenModule &M) const { } 54 55 /// Determines the size of struct _Unwind_Exception on this platform, 56 /// in 8-bit units. The Itanium ABI defines this as: 57 /// struct _Unwind_Exception { 58 /// uint64 exception_class; 59 /// _Unwind_Exception_Cleanup_Fn exception_cleanup; 60 /// uint64 private_1; 61 /// uint64 private_2; 62 /// }; 63 virtual unsigned getSizeOfUnwindException() const; 64 65 /// Controls whether __builtin_extend_pointer should sign-extend 66 /// pointers to uint64_t or zero-extend them (the default). Has 67 /// no effect for targets: 68 /// - that have 64-bit pointers, or 69 /// - that cannot address through registers larger than pointers, or 70 /// - that implicitly ignore/truncate the top bits when addressing 71 /// through such registers. 72 virtual bool extendPointerWithSExt() const { return false; } 73 74 /// Determines the DWARF register number for the stack pointer, for 75 /// exception-handling purposes. Implements __builtin_dwarf_sp_column. 76 /// 77 /// Returns -1 if the operation is unsupported by this target. 78 virtual int getDwarfEHStackPointer(CodeGen::CodeGenModule &M) const { 79 return -1; 80 } 81 82 /// Initializes the given DWARF EH register-size table, a char*. 83 /// Implements __builtin_init_dwarf_reg_size_table. 84 /// 85 /// Returns true if the operation is unsupported by this target. 86 virtual bool initDwarfEHRegSizeTable(CodeGen::CodeGenFunction &CGF, 87 llvm::Value *Address) const { 88 return true; 89 } 90 91 /// Performs the code-generation required to convert a return 92 /// address as stored by the system into the actual address of the 93 /// next instruction that will be executed. 94 /// 95 /// Used by __builtin_extract_return_addr(). 96 virtual llvm::Value *decodeReturnAddress(CodeGen::CodeGenFunction &CGF, 97 llvm::Value *Address) const { 98 return Address; 99 } 100 101 /// Performs the code-generation required to convert the address 102 /// of an instruction into a return address suitable for storage 103 /// by the system in a return slot. 104 /// 105 /// Used by __builtin_frob_return_addr(). 106 virtual llvm::Value *encodeReturnAddress(CodeGen::CodeGenFunction &CGF, 107 llvm::Value *Address) const { 108 return Address; 109 } 110 111 virtual llvm::Type* adjustInlineAsmType(CodeGen::CodeGenFunction &CGF, 112 StringRef Constraint, 113 llvm::Type* Ty) const { 114 return Ty; 115 } 116 117 /// Retrieve the address of a function to call immediately before 118 /// calling objc_retainAutoreleasedReturnValue. The 119 /// implementation of objc_autoreleaseReturnValue sniffs the 120 /// instruction stream following its return address to decide 121 /// whether it's a call to objc_retainAutoreleasedReturnValue. 122 /// This can be prohibitively expensive, depending on the 123 /// relocation model, and so on some targets it instead sniffs for 124 /// a particular instruction sequence. This functions returns 125 /// that instruction sequence in inline assembly, which will be 126 /// empty if none is required. 127 virtual StringRef getARCRetainAutoreleasedReturnValueMarker() const { 128 return ""; 129 } 130 131 /// Determine whether a call to an unprototyped functions under 132 /// the given calling convention should use the variadic 133 /// convention or the non-variadic convention. 134 /// 135 /// There's a good reason to make a platform's variadic calling 136 /// convention be different from its non-variadic calling 137 /// convention: the non-variadic arguments can be passed in 138 /// registers (better for performance), and the variadic arguments 139 /// can be passed on the stack (also better for performance). If 140 /// this is done, however, unprototyped functions *must* use the 141 /// non-variadic convention, because C99 states that a call 142 /// through an unprototyped function type must succeed if the 143 /// function was defined with a non-variadic prototype with 144 /// compatible parameters. Therefore, splitting the conventions 145 /// makes it impossible to call a variadic function through an 146 /// unprototyped type. Since function prototypes came out in the 147 /// late 1970s, this is probably an acceptable trade-off. 148 /// Nonetheless, not all platforms are willing to make it, and in 149 /// particularly x86-64 bends over backwards to make the 150 /// conventions compatible. 151 /// 152 /// The default is false. This is correct whenever: 153 /// - the conventions are exactly the same, because it does not 154 /// matter and the resulting IR will be somewhat prettier in 155 /// certain cases; or 156 /// - the conventions are substantively different in how they pass 157 /// arguments, because in this case using the variadic convention 158 /// will lead to C99 violations. 159 /// It is not necessarily correct when arguments are passed in the 160 /// same way and some out-of-band information is passed for the 161 /// benefit of variadic callees, as is the case for x86-64. 162 /// In this case the ABI should be consulted. 163 virtual bool isNoProtoCallVariadic(CallingConv CC) const; 164 }; 165 } 166 167 #endif // CLANG_CODEGEN_TARGETINFO_H 168
