File Manager

003 File Manager

Current Path: /usr/src/contrib/llvm-project/clang/include/clang/Basic

usr / src / contrib / llvm-project / clang / include / clang / Basic /

📁 ..
📄 AArch64SVEACLETypes.def(7.09 KB)
📄 ABI.h(5.95 KB)
📄 ASTNode.td(120 B)
📄 AddressSpaces.h(2.59 KB)
📄 AlignedAllocation.h(1.38 KB)
📄 AllDiagnostics.h(1.44 KB)
📄 Attr.td(122.78 KB)
📄 AttrDocs.td(197.8 KB)
📄 AttrKinds.h(929 B)
📄 AttrSubjectMatchRules.h(957 B)
📄 AttributeCommonInfo.h(7.02 KB)
📄 Attributes.h(1.35 KB)
📄 BitmaskEnum.h(749 B)
📄 Builtins.def(71.64 KB)
📄 Builtins.h(9.13 KB)
📄 BuiltinsAArch64.def(14.31 KB)
📄 BuiltinsAMDGPU.def(13.1 KB)
📄 BuiltinsARM.def(18.6 KB)
📄 BuiltinsBPF.def(1016 B)
📄 BuiltinsHexagon.def(6.15 KB)
📄 BuiltinsHexagonDep.def(117.26 KB)
📄 BuiltinsHexagonMapCustomDep.def(8.56 KB)
📄 BuiltinsLe64.def(728 B)
📄 BuiltinsMips.def(35.51 KB)
📄 BuiltinsNEON.def(814 B)
📄 BuiltinsNVPTX.def(27.63 KB)
📄 BuiltinsPPC.def(21.53 KB)
📄 BuiltinsSVE.def(786 B)
📄 BuiltinsSystemZ.def(19.7 KB)
📄 BuiltinsWebAssembly.def(10.17 KB)
📄 BuiltinsX86.def(140.49 KB)
📄 BuiltinsX86_64.def(6.79 KB)
📄 BuiltinsXCore.def(846 B)
📄 CapturedStmt.h(662 B)
📄 CharInfo.h(6.52 KB)
📄 CodeGenOptions.def(21.65 KB)
📄 CodeGenOptions.h(14.14 KB)
📄 CommentNodes.td(1.04 KB)
📄 CommentOptions.h(1.1 KB)
📄 Cuda.h(2.3 KB)
📄 DebugInfoOptions.h(1.72 KB)
📄 DeclNodes.td(4.72 KB)
📄 Diagnostic.h(55.73 KB)
📄 Diagnostic.td(5.29 KB)
📄 DiagnosticAST.h(903 B)
📄 DiagnosticASTKinds.td(29.35 KB)
📄 DiagnosticAnalysis.h(933 B)
📄 DiagnosticAnalysisKinds.td(405 B)
📄 DiagnosticCategories.h(757 B)
📄 DiagnosticCategories.td(480 B)
📄 DiagnosticComment.h(927 B)
📄 DiagnosticCommentKinds.td(6.18 KB)
📄 DiagnosticCommonKinds.td(14.32 KB)
📄 DiagnosticCrossTU.h(927 B)
📄 DiagnosticCrossTUKinds.td(889 B)
📄 DiagnosticDocs.td(1.96 KB)
📄 DiagnosticDriver.h(921 B)
📄 DiagnosticDriverKinds.td(25.54 KB)
📄 DiagnosticError.h(1.98 KB)
📄 DiagnosticFrontend.h(933 B)
📄 DiagnosticFrontendKinds.td(13.86 KB)
📄 DiagnosticGroups.td(59.71 KB)
📄 DiagnosticIDs.h(12.83 KB)
📄 DiagnosticLex.h(903 B)
📄 DiagnosticLexKinds.td(38.36 KB)
📄 DiagnosticOptions.def(4.58 KB)
📄 DiagnosticOptions.h(4.21 KB)
📄 DiagnosticParse.h(915 B)
📄 DiagnosticParseKinds.td(68.47 KB)
📄 DiagnosticRefactoring.h(951 B)
📄 DiagnosticRefactoringKinds.td(1.33 KB)
📄 DiagnosticSema.h(909 B)
📄 DiagnosticSemaKinds.td(546.17 KB)
📄 DiagnosticSerialization.h(962 B)
📄 DiagnosticSerializationKinds.td(18.08 KB)
📄 ExceptionSpecificationType.h(2.48 KB)
📄 ExpressionTraits.h(1.18 KB)
📄 FPOptions.def(1.16 KB)
📄 Features.def(11.55 KB)
📄 FileManager.h(16.39 KB)
📄 FileSystemOptions.h(924 B)
📄 FileSystemStatCache.h(3.26 KB)
📄 FixedPoint.h(8.6 KB)
📄 IdentifierTable.h(33.75 KB)
📄 JsonSupport.h(3.69 KB)
📄 LLVM.h(2.43 KB)
📄 Lambda.h(1.37 KB)
📄 LangOptions.def(21.96 KB)
📄 LangOptions.h(18.78 KB)
📄 LangStandard.h(3.87 KB)
📄 LangStandards.def(6.8 KB)
📄 Linkage.h(4.13 KB)
📄 MSP430Target.def(7.04 KB)
📄 MacroBuilder.h(1.34 KB)
📄 Module.h(24.09 KB)
📄 ObjCRuntime.h(14.36 KB)
📄 OpenCLExtensionTypes.def(1.59 KB)
📄 OpenCLExtensions.def(4.38 KB)
📄 OpenCLImageTypes.def(4.1 KB)
📄 OpenCLOptions.h(4.42 KB)
📄 OpenMPKinds.def(4.58 KB)
📄 OpenMPKinds.h(9.66 KB)
📄 OperatorKinds.def(6.56 KB)
📄 OperatorKinds.h(1.55 KB)
📄 OperatorPrecedence.h(1.82 KB)
📄 PartialDiagnostic.h(12.96 KB)
📄 PlistSupport.h(4.02 KB)
📄 PragmaKinds.h(1.21 KB)
📄 PrettyStackTrace.h(1.26 KB)
📄 SanitizerBlacklist.h(1.73 KB)
📄 SanitizerSpecialCaseList.h(1.81 KB)
📄 Sanitizers.def(6.41 KB)
📄 Sanitizers.h(6.57 KB)
📄 SourceLocation.h(15.56 KB)
📄 SourceManager.h(71.11 KB)
📄 SourceManagerInternals.h(4.27 KB)
📄 Specifiers.h(12.68 KB)
📄 Stack.h(1.94 KB)
📄 StmtNodes.td(10.92 KB)
📄 SyncScope.h(4.87 KB)
📄 TargetBuiltins.h(9.18 KB)
📄 TargetCXXABI.h(12.49 KB)
📄 TargetInfo.h(54.4 KB)
📄 TargetOptions.h(3 KB)
📄 TemplateKinds.h(2.22 KB)
📄 TokenKinds.def(33.83 KB)
📄 TokenKinds.h(3.99 KB)
📄 TypeNodes.td(5.48 KB)
📄 TypeTraits.h(2.67 KB)
📄 Version.h(2.23 KB)
📄 Visibility.h(4.4 KB)
📄 X86Target.def(5.21 KB)
📄 XRayInstr.h(1.92 KB)
📄 XRayLists.h(1.73 KB)
📄 arm_bf16.td(590 B)
📄 arm_cde.td(9.29 KB)
📄 arm_fp16.td(5.79 KB)
📄 arm_mve.td(70.85 KB)
📄 arm_mve_defs.td(24.52 KB)
📄 arm_neon.td(90.63 KB)
📄 arm_neon_incl.td(13.64 KB)
📄 arm_sve.td(162.48 KB)

Editing: TargetCXXABI.h

//===--- TargetCXXABI.h - C++ ABI Target Configuration ----------*- C++ -*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
///
/// \file
/// Defines the TargetCXXABI class, which abstracts details of the
/// C++ ABI that we're targeting.
///
//===----------------------------------------------------------------------===//

#ifndef LLVM_CLANG_BASIC_TARGETCXXABI_H
#define LLVM_CLANG_BASIC_TARGETCXXABI_H

#include "llvm/Support/ErrorHandling.h"

namespace clang {

/// The basic abstraction for the target C++ ABI.
class TargetCXXABI {
public:
  /// The basic C++ ABI kind.
  enum Kind {
    /// The generic Itanium ABI is the standard ABI of most open-source
    /// and Unix-like platforms.  It is the primary ABI targeted by
    /// many compilers, including Clang and GCC.
    ///
    /// It is documented here:
    ///   http://www.codesourcery.com/public/cxx-abi/
    GenericItanium,

/// The generic ARM ABI is a modified version of the Itanium ABI
    /// proposed by ARM for use on ARM-based platforms.
    ///
    /// These changes include:
    ///   - the representation of member function pointers is adjusted
    ///     to not conflict with the 'thumb' bit of ARM function pointers;
    ///   - constructors and destructors return 'this';
    ///   - guard variables are smaller;
    ///   - inline functions are never key functions;
    ///   - array cookies have a slightly different layout;
    ///   - additional convenience functions are specified;
    ///   - and more!
    ///
    /// It is documented here:
    ///    http://infocenter.arm.com
    ///                    /help/topic/com.arm.doc.ihi0041c/IHI0041C_cppabi.pdf
    GenericARM,

/// The iOS ABI is a partial implementation of the ARM ABI.
    /// Several of the features of the ARM ABI were not fully implemented
    /// in the compilers that iOS was launched with.
    ///
    /// Essentially, the iOS ABI includes the ARM changes to:
    ///   - member function pointers,
    ///   - guard variables,
    ///   - array cookies, and
    ///   - constructor/destructor signatures.
    iOS,

/// The iOS 64-bit ABI is follows ARM's published 64-bit ABI more
    /// closely, but we don't guarantee to follow it perfectly.
    ///
    /// It is documented here:
    ///    http://infocenter.arm.com
    ///                  /help/topic/com.arm.doc.ihi0059a/IHI0059A_cppabi64.pdf
    iOS64,

/// WatchOS is a modernisation of the iOS ABI, which roughly means it's
    /// the iOS64 ABI ported to 32-bits. The primary difference from iOS64 is
    /// that RTTI objects must still be unique at the moment.
    WatchOS,

/// The generic AArch64 ABI is also a modified version of the Itanium ABI,
    /// but it has fewer divergences than the 32-bit ARM ABI.
    ///
    /// The relevant changes from the generic ABI in this case are:
    ///   - representation of member function pointers adjusted as in ARM.
    ///   - guard variables  are smaller.
    GenericAArch64,

/// The generic Mips ABI is a modified version of the Itanium ABI.
    ///
    /// At the moment, only change from the generic ABI in this case is:
    ///   - representation of member function pointers adjusted as in ARM.
    GenericMIPS,

/// The WebAssembly ABI is a modified version of the Itanium ABI.
    ///
    /// The changes from the Itanium ABI are:
    ///   - representation of member function pointers is adjusted, as in ARM;
    ///   - member functions are not specially aligned;
    ///   - constructors and destructors return 'this', as in ARM;
    ///   - guard variables are 32-bit on wasm32, as in ARM;
    ///   - unused bits of guard variables are reserved, as in ARM;
    ///   - inline functions are never key functions, as in ARM;
    ///   - C++11 POD rules are used for tail padding, as in iOS64.
    ///
    /// TODO: At present the WebAssembly ABI is not considered stable, so none
    /// of these details is necessarily final yet.
    WebAssembly,

/// The Fuchsia ABI is a modified version of the Itanium ABI.
    ///
    /// The relevant changes from the Itanium ABI are:
    ///   - constructors and destructors return 'this', as in ARM.
    Fuchsia,

/// The XL ABI is the ABI used by IBM xlclang compiler and is a modified
    /// version of the Itanium ABI.
    ///
    /// The relevant changes from the Itanium ABI are:
    ///   - static initialization is adjusted to use sinit and sterm functions;
    XL,

/// The Microsoft ABI is the ABI used by Microsoft Visual Studio (and
    /// compatible compilers).
    ///
    /// FIXME: should this be split into Win32 and Win64 variants?
    ///
    /// Only scattered and incomplete official documentation exists.
    Microsoft
  };

private:
  // Right now, this class is passed around as a cheap value type.
  // If you add more members, especially non-POD members, please
  // audit the users to pass it by reference instead.
  Kind TheKind;

public:
  /// A bogus initialization of the platform ABI.
  TargetCXXABI() : TheKind(GenericItanium) {}

TargetCXXABI(Kind kind) : TheKind(kind) {}

void set(Kind kind) {
    TheKind = kind;
  }

Kind getKind() const { return TheKind; }

/// Does this ABI generally fall into the Itanium family of ABIs?
  bool isItaniumFamily() const {
    switch (getKind()) {
    case Fuchsia:
    case GenericAArch64:
    case GenericItanium:
    case GenericARM:
    case iOS:
    case iOS64:
    case WatchOS:
    case GenericMIPS:
    case WebAssembly:
    case XL:
      return true;

case Microsoft:
      return false;
    }
    llvm_unreachable("bad ABI kind");
  }

/// Is this ABI an MSVC-compatible ABI?
  bool isMicrosoft() const {
    switch (getKind()) {
    case Fuchsia:
    case GenericAArch64:
    case GenericItanium:
    case GenericARM:
    case iOS:
    case iOS64:
    case WatchOS:
    case GenericMIPS:
    case WebAssembly:
    case XL:
      return false;

case Microsoft:
      return true;
    }
    llvm_unreachable("bad ABI kind");
  }

/// Are member functions differently aligned?
  ///
  /// Many Itanium-style C++ ABIs require member functions to be aligned, so
  /// that a pointer to such a function is guaranteed to have a zero in the
  /// least significant bit, so that pointers to member functions can use that
  /// bit to distinguish between virtual and non-virtual functions. However,
  /// some Itanium-style C++ ABIs differentiate between virtual and non-virtual
  /// functions via other means, and consequently don't require that member
  /// functions be aligned.
  bool areMemberFunctionsAligned() const {
    switch (getKind()) {
    case WebAssembly:
      // WebAssembly doesn't require any special alignment for member functions.
      return false;
    case Fuchsia:
    case GenericARM:
    case GenericAArch64:
    case GenericMIPS:
      // TODO: ARM-style pointers to member functions put the discriminator in
      //       the this adjustment, so they don't require functions to have any
      //       special alignment and could therefore also return false.
    case GenericItanium:
    case iOS:
    case iOS64:
    case WatchOS:
    case Microsoft:
    case XL:
      return true;
    }
    llvm_unreachable("bad ABI kind");
  }

/// Are arguments to a call destroyed left to right in the callee?
  /// This is a fundamental language change, since it implies that objects
  /// passed by value do *not* live to the end of the full expression.
  /// Temporaries passed to a function taking a const reference live to the end
  /// of the full expression as usual.  Both the caller and the callee must
  /// have access to the destructor, while only the caller needs the
  /// destructor if this is false.
  bool areArgsDestroyedLeftToRightInCallee() const {
    return isMicrosoft();
  }

/// Does this ABI have different entrypoints for complete-object
  /// and base-subobject constructors?
  bool hasConstructorVariants() const {
    return isItaniumFamily();
  }

/// Does this ABI allow virtual bases to be primary base classes?
  bool hasPrimaryVBases() const {
    return isItaniumFamily();
  }

/// Does this ABI use key functions?  If so, class data such as the
  /// vtable is emitted with strong linkage by the TU containing the key
  /// function.
  bool hasKeyFunctions() const {
    return isItaniumFamily();
  }

/// Can an out-of-line inline function serve as a key function?
  ///
  /// This flag is only useful in ABIs where type data (for example,
  /// vtables and type_info objects) are emitted only after processing
  /// the definition of a special "key" virtual function.  (This is safe
  /// because the ODR requires that every virtual function be defined
  /// somewhere in a program.)  This usually permits such data to be
  /// emitted in only a single object file, as opposed to redundantly
  /// in every object file that requires it.
  ///
  /// One simple and common definition of "key function" is the first
  /// virtual function in the class definition which is not defined there.
  /// This rule works very well when that function has a non-inline
  /// definition in some non-header file.  Unfortunately, when that
  /// function is defined inline, this rule requires the type data
  /// to be emitted weakly, as if there were no key function.
  ///
  /// The ARM ABI observes that the ODR provides an additional guarantee:
  /// a virtual function is always ODR-used, so if it is defined inline,
  /// that definition must appear in every translation unit that defines
  /// the class.  Therefore, there is no reason to allow such functions
  /// to serve as key functions.
  ///
  /// Because this changes the rules for emitting type data,
  /// it can cause type data to be emitted with both weak and strong
  /// linkage, which is not allowed on all platforms.  Therefore,
  /// exploiting this observation requires an ABI break and cannot be
  /// done on a generic Itanium platform.
  bool canKeyFunctionBeInline() const {
    switch (getKind()) {
    case Fuchsia:
    case GenericARM:
    case iOS64:
    case WebAssembly:
    case WatchOS:
      return false;

case GenericAArch64:
    case GenericItanium:
    case iOS:   // old iOS compilers did not follow this rule
    case Microsoft:
    case GenericMIPS:
    case XL:
      return true;
    }
    llvm_unreachable("bad ABI kind");
  }

/// When is record layout allowed to allocate objects in the tail
  /// padding of a base class?
  ///
  /// This decision cannot be changed without breaking platform ABI
  /// compatibility. In ISO C++98, tail padding reuse was only permitted for
  /// non-POD base classes, but that restriction was removed retroactively by
  /// DR 43, and tail padding reuse is always permitted in all de facto C++
  /// language modes. However, many platforms use a variant of the old C++98
  /// rule for compatibility.
  enum TailPaddingUseRules {
    /// The tail-padding of a base class is always theoretically
    /// available, even if it's POD.
    AlwaysUseTailPadding,

/// Only allocate objects in the tail padding of a base class if
    /// the base class is not POD according to the rules of C++ TR1.
    UseTailPaddingUnlessPOD03,

/// Only allocate objects in the tail padding of a base class if
    /// the base class is not POD according to the rules of C++11.
    UseTailPaddingUnlessPOD11
  };
  TailPaddingUseRules getTailPaddingUseRules() const {
    switch (getKind()) {
    // To preserve binary compatibility, the generic Itanium ABI has
    // permanently locked the definition of POD to the rules of C++ TR1,
    // and that trickles down to derived ABIs.
    case GenericItanium:
    case GenericAArch64:
    case GenericARM:
    case iOS:
    case GenericMIPS:
    case XL:
      return UseTailPaddingUnlessPOD03;

// iOS on ARM64 and WebAssembly use the C++11 POD rules.  They do not honor
    // the Itanium exception about classes with over-large bitfields.
    case Fuchsia:
    case iOS64:
    case WebAssembly:
    case WatchOS:
      return UseTailPaddingUnlessPOD11;

// MSVC always allocates fields in the tail-padding of a base class
    // subobject, even if they're POD.
    case Microsoft:
      return AlwaysUseTailPadding;
    }
    llvm_unreachable("bad ABI kind");
  }

friend bool operator==(const TargetCXXABI &left, const TargetCXXABI &right) {
    return left.getKind() == right.getKind();
  }

friend bool operator!=(const TargetCXXABI &left, const TargetCXXABI &right) {
    return !(left == right);
  }
};

}  // end namespace clang

#endif

003 File Manager

Editing: TargetCXXABI.h

Upload File

Create Folder