[#index]
= Global namespace
:mrdocs:

== Namespaces

[cols="1,4"]
|===
| Name| Description
| xref:llvm.adoc[`llvm`] 
| Top&hyphen;level LLVM library namespace&period;
|===


== Macros

[cols="1,4"]
|===
| Name| Description
| xref:BEGIN_REGISTER_VP_SDNODE.adoc[`BEGIN&lowbar;REGISTER&lowbar;VP&lowbar;SDNODE`] 
| PTRADD represents pointer arithmetic semantics, for targets that opt in using shouldPreservePtrArith()&period; ptr &equals; PTRADD ptr, offset
| xref:CTXPROF_FUNCTION_DATA.adoc[`CTXPROF&lowbar;FUNCTION&lowbar;DATA`] 
| The internal structure of FunctionData&period; This makes sure that changes to the fields of FunctionData either get automatically captured on the llvm side, or force a manual corresponding update&period;
| xref:DEBUG_WITH_TYPE.adoc[`DEBUG&lowbar;WITH&lowbar;TYPE`] 
| DEBUG&lowbar;WITH&lowbar;TYPE macro &hyphen; This macro should be used by passes to emit debug information&period; If the &apos;&hyphen;debug&apos; option is specified on the commandline, and if this is a debug build, then the code specified as the option to the macro will be executed&period; Otherwise it will not be&period; Example&colon;
| xref:DECLARE_TRANSPARENT_OPERAND_ACCESSORS.adoc[`DECLARE&lowbar;TRANSPARENT&lowbar;OPERAND&lowbar;ACCESSORS`] 
| Macro for generating in&hyphen;class operand accessor declarations&period; It should only be called in the public section of the interface&period;
| xref:DEFINE_TRANSPARENT_OPERAND_ACCESSORS.adoc[`DEFINE&lowbar;TRANSPARENT&lowbar;OPERAND&lowbar;ACCESSORS`] 
| Macro for generating out&hyphen;of&hyphen;class operand accessor definitions
| xref:GET_RUNTIME_LIBCALL_ENUM.adoc[`GET&lowbar;RUNTIME&lowbar;LIBCALL&lowbar;ENUM`] 
| TableGen will produce 2 enums, RTLIB&colon;&colon;Libcall and RTLIB&colon;&colon;LibcallImpl&period; RTLIB&colon;&colon;Libcall describes abstract functionality the compiler may choose to access, RTLIB&colon;&colon;LibcallImpl describes a particular ABI implementation, which includes a name and type signature&period;
| xref:GET_RUNTIME_LIBCALL_FP_SELECTOR_DECLS.adoc[`GET&lowbar;RUNTIME&lowbar;LIBCALL&lowbar;FP&lowbar;SELECTOR&lowbar;DECLS`] 
| The floating&hyphen;point selectors get&lt;OP&gt;(EVT) return the &lt;OP&gt; libcall for the given type, or UNKNOWN&lowbar;LIBCALL&period; Generated from the RuntimeLibcallFamily table in RuntimeLibcalls&period;td&period;
| xref:HANDLE_BINARY_INST.adoc[`HANDLE&lowbar;BINARY&lowbar;INST`] 
| These methods just forward to Create, and are useful when you statically know what type of instruction you&apos;re going to create&period; These helpers just save some typing&period;
| xref:HANDLE_DIEVALUE_SMALL.adoc[`HANDLE&lowbar;DIEVALUE&lowbar;SMALL`] 
| @&rcub;
| xref:HANDLE_DW_SECT.adoc[`HANDLE&lowbar;DW&lowbar;SECT`] 
| Denotes a value read from an index section that does not correspond to any of the supported standards&period;
| xref:HANDLE_UNARY_INST.adoc[`HANDLE&lowbar;UNARY&lowbar;INST`] 
| These methods just forward to Create, and are useful when you statically know what type of instruction you&apos;re going to create&period; These helpers just save some typing&period;
| xref:LAST_OTHER_INST.adoc[`LAST&lowbar;OTHER&lowbar;INST`] 
| Vocabulary layout constants
| xref:LDBG.adoc[`LDBG`] 
| output&period; The default level is 1, and is in increasing level of verbosity&period;
| xref:LDBG_GET_DEBUG_TYPE_STR__.adoc[`LDBG&lowbar;GET&lowbar;DEBUG&lowbar;TYPE&lowbar;STR&lowbar;&lowbar;`] 
| Helpers to get DEBUG&lowbar;TYPE as a StringRef, even when DEBUG&lowbar;TYPE is not defined (in which case it expands to &quot;DEBUG&lowbar;TYPE&quot;)
| xref:LDBG_GET_DEFAULT_TYPE_OR_LEVEL.adoc[`LDBG&lowbar;GET&lowbar;DEFAULT&lowbar;TYPE&lowbar;OR&lowbar;LEVEL`] 
| Helper to provide the default level (&equals;1) or type (&equals;DEBUG&lowbar;TYPE)&period; This is used when a single argument is passed to LDBG() (or LDBG&lowbar;OS()), if it is an integer we return DEBUG&lowbar;TYPE and if it is a string we return 1&period; When DEBUG&lowbar;TYPE is not defined, we return the current file name instead&period;
| xref:LDBG_LEVEL_OR_TYPE.adoc[`LDBG&lowbar;LEVEL&lowbar;OR&lowbar;TYPE`] 
| When a single argument is provided&period; This can be either a level or the debug type&period; If a level is provided, we default the debug type to DEBUG&lowbar;TYPE, if a string is provided, we default the level to 1&period;
| xref:LDBG_OS.adoc[`LDBG&lowbar;OS`] 
| LDBG&lowbar;OS() is a macro that behaves like LDBG() but instead of directly using it to stream the output, it takes a callback function that will be called with a raw&lowbar;ostream&period; This is useful when you need to pass a `raw&lowbar;ostream` to a helper function to be able to print (when the `&lt;&lt;` operator is not available)&period;
| xref:LDBG_OS_IMPL.adoc[`LDBG&lowbar;OS&lowbar;IMPL`] 
| This macro is the core of the LDBG&lowbar;OS() macros&period; It is used to print the debug output with the given stream, level, type, file, and line number&period;
| xref:LDBG_STREAM.adoc[`LDBG&lowbar;STREAM`] 
| This macro expands to the stream to use for output, we use a macro to allow unit&hyphen;testing to override&period;
| xref:LDBG_STREAM_LEVEL_TYPE_AND_FILE.adoc[`LDBG&lowbar;STREAM&lowbar;LEVEL&lowbar;TYPE&lowbar;AND&lowbar;FILE`] 
| These macros are helpers to implement LDBG() with an increasing amount of optional arguments made explicit&period;
| xref:LDBG_STREAM_LEVEL_TYPE_FILE_AND_LINE.adoc[`LDBG&lowbar;STREAM&lowbar;LEVEL&lowbar;TYPE&lowbar;FILE&lowbar;AND&lowbar;LINE`] 
| This macro is the core of the LDBG() implementation&period; It is used to print the debug output with the given stream, level, type, file, and line number&period;
| xref:LDBG_TYPE_AND_LEVEL.adoc[`LDBG&lowbar;TYPE&lowbar;AND&lowbar;LEVEL`] 
| This macro is a helper when LDBG() is called with 2 arguments&period; In this case we want to force the first argument to be the type for consistency in the codebase&period; We trick this by casting the first argument to a (const char &ast;) which won&apos;t compile with an int&period;
| xref:LLVM_DECLARE_ENUM_AS_BITMASK.adoc[`LLVM&lowbar;DECLARE&lowbar;ENUM&lowbar;AS&lowbar;BITMASK`] 
| LLVM&lowbar;DECLARE&lowbar;ENUM&lowbar;AS&lowbar;BITMASK can be used to declare an enum type as a bit set, so that bitwise operation on such enum does not require static&lowbar;cast&period;
| xref:LLVM_DECLARE_REGISTRY.adoc[`LLVM&lowbar;DECLARE&lowbar;REGISTRY`] 
| Helper macro to declare registry class&period;
| xref:LLVM_DECLARE_REGISTRY_EX.adoc[`LLVM&lowbar;DECLARE&lowbar;REGISTRY&lowbar;EX`] 
| Variants of the registration macros that take an explicit export annotation (EXPORT&lowbar;ABI) in place of the hard&hyphen;coded `LLVM&lowbar;ABI&lowbar;EXPORT`&period; Use these when a registry is owned by a component that is NOT part of the LLVM dylib&period; For example, a clang library that is statically linked (`CLANG&lowbar;LINK&lowbar;CLANG&lowbar;DYLIB` OFF)&period; With `LLVM&lowbar;ABI&lowbar;EXPORT` the `getRegistryLinkListInstance` accessor is unconditionally `dllexport`ed&semi; when such a static component is embedded in a DLL that should only export its own API surface (e&period;g&period; libclang&period;dll), the accessor leaks into that DLL&apos;s export table and then collides on the link line of any tool that also links the static component directly&period;
| xref:LLVM_DEFINE_REGISTRY.adoc[`LLVM&lowbar;DEFINE&lowbar;REGISTRY`] 
| Helper macro to define registry class&period;
| xref:LLVM_ENABLE_BITMASK_ENUMS_IN_NAMESPACE.adoc[`LLVM&lowbar;ENABLE&lowbar;BITMASK&lowbar;ENUMS&lowbar;IN&lowbar;NAMESPACE`] 
| LLVM&lowbar;ENABLE&lowbar;BITMASK&lowbar;ENUMS&lowbar;IN&lowbar;NAMESPACE() pulls the operator overloads used by LLVM&lowbar;MARK&lowbar;AS&lowbar;BITMASK&lowbar;ENUM into the current namespace&period;
| xref:LLVM_MARK_AS_BITMASK_ENUM.adoc[`LLVM&lowbar;MARK&lowbar;AS&lowbar;BITMASK&lowbar;ENUM`] 
| LLVM&lowbar;MARK&lowbar;AS&lowbar;BITMASK&lowbar;ENUM lets you opt in an individual enum type so you can perform bitwise operations on it without putting static&lowbar;cast everywhere&period;
| xref:LLVM_PLUGIN_API_VERSION.adoc[`LLVM&lowbar;PLUGIN&lowbar;API&lowbar;VERSION`] 
| macro LLVM&lowbar;PLUGIN&lowbar;API&lowbar;VERSION Identifies the API version understood by this plugin&period;
| xref:LLVM_YAML_IS_DOCUMENT_LIST_VECTOR.adoc[`LLVM&lowbar;YAML&lowbar;IS&lowbar;DOCUMENT&lowbar;LIST&lowbar;VECTOR`] 
| Utility for declaring that a std&colon;&colon;vector of a particular type should be considered a YAML document list&period;
| xref:LLVM_YAML_IS_FLOW_SEQUENCE_VECTOR.adoc[`LLVM&lowbar;YAML&lowbar;IS&lowbar;FLOW&lowbar;SEQUENCE&lowbar;VECTOR`] 
| Utility for declaring that a std&colon;&colon;vector of a particular type should be considered a YAML flow sequence&period;
| xref:LLVM_YAML_IS_SEQUENCE_VECTOR.adoc[`LLVM&lowbar;YAML&lowbar;IS&lowbar;SEQUENCE&lowbar;VECTOR`] 
| Utility for declaring that a std&colon;&colon;vector of a particular type should be considered a YAML sequence&period;
| xref:LLVM_YAML_IS_STRING_MAP.adoc[`LLVM&lowbar;YAML&lowbar;IS&lowbar;STRING&lowbar;MAP`] 
| Utility for declaring that std&colon;&colon;map&lt;std&colon;&colon;string, &lowbar;type&gt; should be considered a YAML map&period;
| xref:LLVM_YAML_STRONG_TYPEDEF.adoc[`LLVM&lowbar;YAML&lowbar;STRONG&lowbar;TYPEDEF`] 
| YAML I&sol;O does conversion based on types&period; But often native data types are just a typedef of built in intergral types (e&period;g&period; int)&period; But the C&plus;&plus; type matching system sees through the typedef and all the typedefed types look like a built in type&period; This will cause the generic YAML I&sol;O conversion to be used&period; To provide better control over the YAML conversion, you can use this macro instead of typedef&period; It will create a class with one field and automatic conversion operators to and from the base type&period; Based on BOOST&lowbar;STRONG&lowbar;TYPEDEF
| xref:MAKE_CAS_HANDLE_CONSTRUCTOR.adoc[`MAKE&lowbar;CAS&lowbar;HANDLE&lowbar;CONSTRUCTOR`] 
| Allow ObjectStore implementations to create internal handles&period;
| xref:OMP_TYPE.adoc[`OMP&lowbar;TYPE`] 
| Declarations for LLVM&hyphen;IR types (simple, array, function and structure) are generated below&period; Their names are defined and used in OpenMPKinds&period;def&period; Here we provide the declarations, the initializeTypes function will provide the values&period;
| xref:R_TYPE_SHIFT.adoc[`R&lowbar;TYPE&lowbar;SHIFT`] 
| @&rcub;
| xref:SUPPORTED_TENSOR_TYPES.adoc[`SUPPORTED&lowbar;TENSOR&lowbar;TYPES`] 
| TensorSpec encapsulates the specification of a tensor&colon; its dimensions, or &quot;shape&quot; (row&hyphen;major), its type (see TensorSpec&colon;&colon;getDataType specializations for supported types), its name and port (see &quot;TensorFlow&colon; Large&hyphen;Scale Machine Learning on Heterogeneous Distributed Systems&quot;, section 4&period;2, para 2&colon; https&colon;&sol;&sol;static&period;googleusercontent&period;com&sol;media&sol;research&period;google&period;com&sol;en&sol;&sol;pubs&sol;archive&sol;45166&period;pdf)
|===


== Using Namespace Directives

[cols="1,4"]
|===
| Name| Description
| xref:llvm/support/endian.adoc[`endian`] 
| Helpers to read and write values with an explicit byte order&period;
| xref:llvm.adoc[`llvm`] 
| Top&hyphen;level LLVM library namespace&period;
|===



[.small]#Created with https://www.mrdocs.com[MrDocs]#
