clang 22.0.0git
Public Member Functions | List of all members
clang::CIRGen::TargetCIRGenInfo Class Reference

#include "/home/buildbot/as-worker-4/publish-doxygen-docs/llvm-project/clang/lib/CIR/CodeGen/TargetInfo.h"

Public Member Functions

 TargetCIRGenInfo (std::unique_ptr< ABIInfo > info)
 
virtual ~TargetCIRGenInfo ()=default
 
const ABIInfogetABIInfo () const
 Returns ABI info helper for the target.
 
virtual bool isNoProtoCallVariadic (const FunctionNoProtoType *fnType) const
 Determine whether a call to an unprototyped functions under the given calling convention should use the variadic convention or the non-variadic convention.
 

Detailed Description

Definition at line 35 of file TargetInfo.h.

Constructor & Destructor Documentation

◆ TargetCIRGenInfo()

clang::CIRGen::TargetCIRGenInfo::TargetCIRGenInfo ( std::unique_ptr< ABIInfo info)
inline

Definition at line 39 of file TargetInfo.h.

◆ ~TargetCIRGenInfo()

virtual clang::CIRGen::TargetCIRGenInfo::~TargetCIRGenInfo ( )
virtualdefault

Member Function Documentation

◆ getABIInfo()

const ABIInfo & clang::CIRGen::TargetCIRGenInfo::getABIInfo ( ) const
inline

Returns ABI info helper for the target.

Definition at line 44 of file TargetInfo.h.

◆ isNoProtoCallVariadic()

bool TargetCIRGenInfo::isNoProtoCallVariadic ( const FunctionNoProtoType fnType) const
virtual

Determine whether a call to an unprototyped functions under the given calling convention should use the variadic convention or the non-variadic convention.

There's a good reason to make a platform's variadic calling convention be different from its non-variadic calling convention: the non-variadic arguments can be passed in registers (better for performance), and the variadic arguments can be passed on the stack (also better for performance). If this is done, however, unprototyped functions must use the non-variadic convention, because C99 states that a call through an unprototyped function type must succeed if the function was defined with a non-variadic prototype with compatible parameters. Therefore, splitting the conventions makes it impossible to call a variadic function through an unprototyped type. Since function prototypes came out in the late 1970s, this is probably an acceptable trade-off. Nonetheless, not all platforms are willing to make it, and in particularly x86-64 bends over backwards to make the conventions compatible.

The default is false. This is correct whenever:

  • the conventions are exactly the same, because it does not matter and the resulting IR will be somewhat prettier in certain cases; or
  • the conventions are substantively different in how they pass arguments, because in this case using the variadic convention will lead to C99 violations.

However, some platforms make the conventions identical except for passing additional out-of-band information to a variadic function: for example, x86-64 passes the number of SSE arguments in al. On these platforms, it is desirable to call unprototyped functions using the variadic convention so that unprototyped calls to varargs functions still succeed.

Relatedly, platforms which pass the fixed arguments to this: A foo(B, C, D); differently than they would pass them to this: A foo(B, C, D, ...); may need to adjust the debugger-support code in Sema to do the right thing when calling a function with no know signature.

Definition at line 63 of file TargetInfo.cpp.

Referenced by arrangeFreeFunctionLikeCall().


The documentation for this class was generated from the following files: