diff options
Diffstat (limited to 'llvm/docs')
| -rw-r--r-- | llvm/docs/AMDGPUUsage.rst | 8 | ||||
| -rw-r--r-- | llvm/docs/CodeOfConduct.rst | 1 | ||||
| -rw-r--r-- | llvm/docs/CommandGuide/dsymutil.rst | 8 | ||||
| -rw-r--r-- | llvm/docs/HowToReleaseLLVM.rst | 82 | ||||
| -rw-r--r-- | llvm/docs/LangRef.rst | 25 | ||||
| -rw-r--r-- | llvm/docs/ReleaseNotes.md | 1 | ||||
| -rw-r--r-- | llvm/docs/SPIRVUsage.rst | 2 | ||||
| -rw-r--r-- | llvm/docs/TableGen/BackEnds.rst | 50 |
8 files changed, 92 insertions, 85 deletions
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst index 402fd05..e062032 100644 --- a/llvm/docs/AMDGPUUsage.rst +++ b/llvm/docs/AMDGPUUsage.rst @@ -488,21 +488,21 @@ Every processor supports every OS ABI (see :ref:`amdgpu-os`) with the following **GCN GFX11 (RDNA 3.5)** [AMD-GCN-GFX11-RDNA3.5]_ ----------------------------------------------------------------------------------------------------------------------- - ``gfx1150`` ``amdgcn`` APU - cumode - Architected *TBA* + ``gfx1150`` ``amdgcn`` APU - cumode - Architected Radeon 890M - wavefrontsize64 flat scratch .. TODO:: - Packed work-item Add product IDs names. - ``gfx1151`` ``amdgcn`` APU - cumode - Architected *TBA* + ``gfx1151`` ``amdgcn`` APU - cumode - Architected Radeon 8060S - wavefrontsize64 flat scratch .. TODO:: - Packed work-item Add product IDs names. - ``gfx1152`` ``amdgcn`` APU - cumode - Architected *TBA* + ``gfx1152`` ``amdgcn`` APU - cumode - Architected Radeon 860M - wavefrontsize64 flat scratch .. TODO:: - Packed @@ -883,6 +883,8 @@ supported for the ``amdgcn`` target. Buffer Fat Pointer 7 N/A N/A 160 0 Buffer Resource 8 N/A V# 128 0x00000000000000000000000000000000 Buffer Strided Pointer (experimental) 9 *TODO* + *reserved for downstream use* 10 + *reserved for downstream use* 11 Streamout Registers 128 N/A GS_REGS ===================================== =============== =========== ================ ======= ============================ diff --git a/llvm/docs/CodeOfConduct.rst b/llvm/docs/CodeOfConduct.rst index 645ae12..995d32b 100644 --- a/llvm/docs/CodeOfConduct.rst +++ b/llvm/docs/CodeOfConduct.rst @@ -171,6 +171,7 @@ The current committee members are: Transparency Reports ==================== +* `July 15, 2025 <https://discourse.llvm.org/t/llvm-code-of-conduct-transparency-report-july-15-2024-july-15-2025/88622>`_ * `July 15, 2024 <https://discourse.llvm.org/t/llvm-code-of-conduct-transparency-report-july-15-2023-july-15-2024/82687>`_ * `July 15, 2023 <https://llvm.org/coc-reports/2023-07-15-report.html>`_ * `July 15, 2022 <https://llvm.org/coc-reports/2022-07-15-report.html>`_ diff --git a/llvm/docs/CommandGuide/dsymutil.rst b/llvm/docs/CommandGuide/dsymutil.rst index 8764e1f..8e61e01 100644 --- a/llvm/docs/CommandGuide/dsymutil.rst +++ b/llvm/docs/CommandGuide/dsymutil.rst @@ -75,14 +75,6 @@ OPTIONS Make a static variable keep the enclosing function even if it would have been omitted otherwise. -.. option:: --minimize, -z - - When used when creating a dSYM file, this option will suppress the emission of - the .debug_inlines, .debug_pubnames, and .debug_pubtypes sections since - dsymutil currently has better equivalents: .apple_names and .apple_types. When - used in conjunction with ``--update`` option, this option will cause redundant - accelerator tables to be removed. - .. option:: --no-object-timestamp Don't check timestamp for object files. diff --git a/llvm/docs/HowToReleaseLLVM.rst b/llvm/docs/HowToReleaseLLVM.rst index 1795d3a..171bf88 100644 --- a/llvm/docs/HowToReleaseLLVM.rst +++ b/llvm/docs/HowToReleaseLLVM.rst @@ -18,11 +18,11 @@ create the binary packages, please refer to the :doc:`ReleaseProcess` instead. Release Timeline ================ -LLVM is released on a time based schedule --- with major releases roughly +LLVM is released on a time-based schedule --- with major releases roughly every 6 months. In between major releases there may be dot releases. The release manager will determine if and when to make a dot release based on feedback from the community. Typically, dot releases should be made if -there are large number of bug-fixes in the stable branch or a critical bug +there are a large number of bug fixes in the stable branch or a critical bug has been discovered that affects a large number of users. Unless otherwise stated, dot releases will follow the same procedure as @@ -73,7 +73,7 @@ Release Process Summary * Generate and send out the second release candidate sources. Only *critical* bugs found during this testing phase will be fixed. Any bugs introduced by - merged patches will be fixed. If so a third round of testing is needed. + merged patches will be fixed. If so, a third round of testing is needed. * The release notes are updated. @@ -107,15 +107,15 @@ Create Release Branch and Update LLVM Version Branch the Git trunk using the following procedure: #. Remind developers that the release branching is imminent and to refrain from - committing patches that might break the build. E.g., new features, large + committing patches that might break the build, e.g., new features, large patches for works in progress, an overhaul of the type system, an exciting new TableGen feature, etc. #. Verify that the current git trunk is in decent shape by examining nightly tester and buildbot results. -#. Bump the version in trunk to N.0.0git with the script in - ``llvm/utils/release/bump-version.py``, and tag the commit with llvmorg-N-init. +#. Bump the version in trunk to ``N.0.0git`` with the script in + ``llvm/utils/release/bump-version.py``, and tag the commit with ``llvmorg-N-init``. If ``X`` is the version to be released, then ``N`` is ``X + 1``. :: $ git tag -sa llvmorg-N-init @@ -124,14 +124,14 @@ Branch the Git trunk using the following procedure: ``llvm/utils/release/clear-release-notes.py``. #. Create the release branch from the last known good revision from before the - version bump. The branch's name is release/X.x where ``X`` is the major version + version bump. The branch's name is ``release/X.x`` where ``X`` is the major version number and ``x`` is just the letter ``x``. #. On the newly-created release branch, immediately bump the version - to X.1.0git (where ``X`` is the major version of the branch.) + to ``X.1.0git`` (where ``X`` is the major version of the branch.) -#. All tags and branches need to be created in both the llvm/llvm-project and - llvm/llvm-test-suite repos. +#. All tags and branches need to be created in both the ``llvm/llvm-project`` and + ``llvm/llvm-test-suite`` repos. Tagging the LLVM Release Candidates ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -157,7 +157,7 @@ the release page. $ for f in *.xz; do gh attestation verify --owner llvm $f && gpg -b $f; done Tarballs, release binaries, or any other release artifacts must be uploaded to -GitHub. This can be done using the github-upload-release.py script in utils/release. +GitHub. This can be done using the ``github-upload-release.py`` script in ``utils/release``. :: @@ -170,10 +170,10 @@ Build The Binary Distribution Creating the binary distribution requires following the instructions :doc:`here <ReleaseProcess>`. -That process will perform both Release+Asserts and Release builds but only -pack the Release build for upload. You should use the Release+Asserts sysroot, +That process performs both Release+Asserts and Release builds but only packs +the Release build for upload. You should use the Release+Asserts sysroot, normally under ``final/Phase3/Release+Asserts/llvmCore-3.8.1-RCn.install/``, -for test-suite and run-time benchmarks, to make sure nothing serious has +for test-suite and run-time benchmarks, to ensure nothing serious has passed through the net. For compile-time benchmarks, use the Release version. The minimum required version of the tools you'll need are :doc:`here <GettingStarted>` @@ -181,14 +181,14 @@ The minimum required version of the tools you'll need are :doc:`here <GettingSta Release Qualification Criteria ------------------------------ -There are no official release qualification criteria. It is up to the -the release manager to determine when a release is ready. The release manager +There are no official release qualification criteria. +The release manager determines when a release is ready. The release manager should pay attention to the results of community testing, the number of outstanding -bugs, and then number of regressions when determining whether or not to make a +bugs, and the number of regressions when determining whether or not to make a release. The community values time based releases, so releases should not be delayed for -too long unless there are critical issues remaining. In most cases, the only +too long unless critical issues remain. In most cases, the only kind of bugs that are critical enough to block a release would be a major regression from a previous release. @@ -199,33 +199,33 @@ A few developers in the community have dedicated time to validate the release candidates and volunteered to be the official release testers for each architecture. -These will be the ones testing, generating and uploading the official binaries +These will be the ones testing, generating, and uploading the official binaries to the server, and will be the minimum tests *necessary* for the release to proceed. This will obviously not cover all OSs and distributions, so additional community -validation is important. However, if community input is not reached before the -release is out, all bugs reported will have to go on the next stable release. +validation is important. However, if community input is not received before the +release, all reported bugs will be deferred to the next stable release. The official release managers are: * Even releases: Tom Stellard (tstellar@redhat.com) * Odd releases: Tobias Hieta (tobias@hieta.se) -The official release testers are volunteered from the community and have +The official release testers are volunteers from the community who have consistently validated and released binaries for their targets/OSs. To contact them, you should post on the `Discourse forums (Project Infrastructure - Release Testers). <https://discourse.llvm.org/c/infrastructure/release-testers/66>`_ -The official testers list is in the file `RELEASE_TESTERS.TXT +The official testers list is in the file ``RELEASE_TESTERS.TXT`` <https://github.com/llvm/llvm-project/blob/main/llvm/RELEASE_TESTERS.TXT>`_, in the LLVM repository. Community Testing ----------------- -Once all testing has been completed and appropriate bugs filed, the release -candidate tarballs are put on the website and the LLVM community is notified. +Once all testing is complete and appropriate bugs are filed, the release +candidate tarballs are put on the website, and the LLVM community is notified. We ask that all LLVM developers test the release in any the following ways: @@ -251,7 +251,7 @@ We ask that all LLVM developers test the release in any the following ways: architecture. We also ask that the OS distribution release managers test their packages with -the first candidate of every release, and report any *new* errors in GitHub. +the first candidate of every release and report any *new* errors in GitHub. If the bug can be reproduced with an unpatched upstream version of the release candidate (as opposed to the distribution's own build), the priority should be release blocker. @@ -268,10 +268,10 @@ next stage. Reporting Regressions --------------------- -Every regression that is found during the tests (as per the criteria above), +Every regression found during the tests (as per the criteria above) should be filled in a bug in GitHub and added to the release milestone. -If a bug can't be reproduced, or stops being a blocker, it should be removed +If a bug can't be reproduced or stops being a blocker, it should be removed from the Milestone. Debugging can continue, but on trunk. Backport Requests @@ -299,15 +299,15 @@ This section describes how to triage bug reports: to see the list of bugs that are being considered for the release. #. Review each bug and first check if it has been fixed in main. If it has, update - its status to "Needs Pull Request", and create a pull request for the fix - using the /cherry-pick or /branch comments if this has not been done already. + its status to "Needs Pull Request" and create a pull request for the fix + using the ``/cherry-pick`` or ``/branch`` comments if this has not been done already. #. If a bug has been fixed and has a pull request created for backporting it, then update its status to "Needs Review" and notify a knowledgeable reviewer. Usually you will want to notify the person who approved the patch, but you may use your best judgement on who a good reviewer would be. Once you have identified the reviewer(s), assign the issue to them and - mention them (i.e @username) in a comment and ask them if the patch is safe + mention them (i.e., ``@username``) in a comment and ask them if the patch is safe to backport. You should also review the bug yourself to ensure that it meets the requirements for committing to the release branch. @@ -323,11 +323,11 @@ Release Patch Rules Below are the rules regarding patching the release branch: #. Patches applied to the release branch may only be applied by the release - manager, the official release testers or the maintainers with approval from + manager, the official release testers, or the maintainers with approval from the release manager. #. Release managers are encouraged, but not required, to get approval from a - maintainer before approving patches. If there are no reachable maintainers + maintainer before approving patches. If there are no reachable maintainers, then release managers can ask approval from patch reviewers or other developers active in that area. @@ -336,7 +336,7 @@ Below are the rules regarding patching the release branch: was created. As with all phases, release managers and maintainers can reject patches that are deemed too invasive. -#. *Before RC2/RC3* Patches should be limited to bug fixes or backend specific +#. *Before RC2/RC3* Patches should be limited to bug fixes or backend-specific improvements that are determined to be very safe. #. *Before Final Major Release* Patches should be limited to critical @@ -349,7 +349,7 @@ Below are the rules regarding patching the release branch: Release Final Tasks ------------------- -The final stages of the release process involves tagging the "final" release +The final stages of the release process involve tagging the "final" release branch, updating documentation that refers to the release, and updating the demo page. @@ -394,11 +394,11 @@ is what to do: #. Update the ``releases/index.html`` with the new release and link to release documentation. -#. After you push the changes to the www-releases repo, someone with admin - access must login to prereleases-origin.llvm.org and manually pull the new - changes into /data/www-releases/. This is where the website is served from. +#. After you push the changes to the ``www-releases`` repo, someone with admin + access must log in to ``prereleases-origin.llvm.org`` and manually pull the new + changes into ``/data/www-releases/``. This is where the website is served from. -#. Finally checkout the llvm-www repo and update the main page +#. Finally, check out the ``llvm-www`` repo and update the main page (``index.html`` and sidebar) to point to the new release and release announcement. @@ -414,5 +414,5 @@ using this command and add it to the post. $ git log --format="- %aN: [%s (%h)](https://github.com/llvm/llvm-project/commit/%H)" llvmorg-X.1.N-1..llvmorg-X.1.N -Once the release has been announced add a link to the announcement on the llvm -homepage (from the llvm-www repo) in the "Release Emails" section. +Once the release has been announced, add a link to the announcement on the llvm +homepage (from the ``llvm-www`` repo) in the "Release Emails" section. diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 0c54f57..5b4b53d 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -21062,12 +21062,15 @@ integer element type. Syntax: """"""" -This is an overloaded intrinsic. +This is an overloaded intrinsic. You can use ``llvm.matrix.column.major.load`` +to load any vector type with a stride of any bitwidth up to 64. :: - declare vectorty @llvm.matrix.column.major.load.*( + declare <4 x i32> @llvm.matrix.column.major.load.v4i32.i64( ptrty %Ptr, i64 %Stride, i1 <IsVolatile>, i32 <Rows>, i32 <Cols>) + declare <9 x double> @llvm.matrix.column.major.load.v9f64.i32( + ptrty %Ptr, i32 %Stride, i1 <IsVolatile>, i32 <Rows>, i32 <Cols>) Overview: """"""""" @@ -21086,9 +21089,9 @@ Arguments: The first argument ``%Ptr`` is a pointer type to the returned vector type, and corresponds to the start address to load from. The second argument ``%Stride`` -is a positive, constant integer with ``%Stride >= <Rows>``. ``%Stride`` is used -to compute the column memory addresses. I.e., for a column ``C``, its start -memory addresses is calculated with ``%Ptr + C * %Stride``. The third Argument +is a positive integer for which ``%Stride >= <Rows>``. ``%Stride`` is used to +compute the column memory addresses. I.e., for a column ``C``, its start memory +addresses is calculated with ``%Ptr + C * %Stride``. The third Argument ``<IsVolatile>`` is a boolean value. The fourth and fifth arguments, ``<Rows>`` and ``<Cols>``, correspond to the number of rows and columns, respectively, and must be positive, constant integers. The returned vector must @@ -21103,11 +21106,17 @@ The :ref:`align <attr_align>` parameter attribute can be provided for the Syntax: """"""" +This is an overloaded intrinsic. ``llvm.matrix.column.major.store`` to store +any vector type with a stride of any bitwidth up to 64. :: - declare void @llvm.matrix.column.major.store.*( - vectorty %In, ptrty %Ptr, i64 %Stride, i1 <IsVolatile>, i32 <Rows>, i32 <Cols>) + declare void @llvm.matrix.column.major.store.v4i32.i64( + <4 x i32> %In, ptrty %Ptr, i64 %Stride, i1 <IsVolatile>, i32 <Rows>, + i32 <Cols>) + declare void @llvm.matrix.column.major.store.v9f64.i32( + <9 x double> %In, ptrty %Ptr, i32 %Stride, i1 <IsVolatile>, i32 + <Rows>, i32 <Cols>) Overview: """"""""" @@ -21127,7 +21136,7 @@ Arguments: The first argument ``%In`` is a vector that corresponds to a ``<Rows> x <Cols>`` matrix to be stored to memory. The second argument ``%Ptr`` is a pointer to the vector type of ``%In``, and is the start address of the matrix -in memory. The third argument ``%Stride`` is a positive, constant integer with +in memory. The third argument ``%Stride`` is a positive integer for which ``%Stride >= <Rows>``. ``%Stride`` is used to compute the column memory addresses. I.e., for a column ``C``, its start memory addresses is calculated with ``%Ptr + C * %Stride``. The fourth argument ``<IsVolatile>`` is a boolean diff --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md index c352cd6..9cdd983 100644 --- a/llvm/docs/ReleaseNotes.md +++ b/llvm/docs/ReleaseNotes.md @@ -140,6 +140,7 @@ Changes to the X86 Backend -------------------------- * `-mcpu=wildcatlake` is now supported. +* `-mcpu=novalake` is now supported. Changes to the OCaml bindings ----------------------------- diff --git a/llvm/docs/SPIRVUsage.rst b/llvm/docs/SPIRVUsage.rst index d2d6646..85eeabf 100644 --- a/llvm/docs/SPIRVUsage.rst +++ b/llvm/docs/SPIRVUsage.rst @@ -235,6 +235,8 @@ Below is a list of supported SPIR-V extensions, sorted alphabetically by their e - Adds execution modes and decorations to control floating-point computations in both kernels and shaders. It can be used on whole modules and individual instructions. * - ``SPV_INTEL_predicated_io`` - Adds predicated load and store instructions that conditionally read from or write to memory based on a boolean predicate. + * - ``SPV_KHR_maximal_reconvergence`` + - Adds execution mode and capability to enable maximal reconvergence. SPIR-V representation in LLVM IR ================================ diff --git a/llvm/docs/TableGen/BackEnds.rst b/llvm/docs/TableGen/BackEnds.rst index 14232bc..7f57137 100644 --- a/llvm/docs/TableGen/BackEnds.rst +++ b/llvm/docs/TableGen/BackEnds.rst @@ -48,7 +48,7 @@ the TableGen files, the back-ends and their users. For instance, a global contract is that each back-end produces macro-guarded sections. Based on whether the file is included by a header or a source file, or even in which context of each file the include is being used, you have -todefine a macro just before including it, to get the right output: +to define a macro just before including it, to get the right output: .. code-block:: c++ @@ -80,8 +80,8 @@ in the TableGen files. CodeEmitter ----------- -**Purpose**: CodeEmitterGen uses the descriptions of instructions and their fields to -construct an automated code emitter: a function that, given a MachineInstr, +**Purpose**: ``CodeEmitterGen`` uses the descriptions of instructions and their fields to +construct an automated code emitter: a function that, given a ``MachineInstr``, returns the (currently, 32-bit unsigned) value of the instruction. **Output**: C++ code, implementing the target's CodeEmitter @@ -130,7 +130,7 @@ AsmMatcher ---------- **Purpose**: Emits a target specifier matcher for -converting parsed assembly operands in the MCInst structures. It also +converting parsed assembly operands in the ``MCInst`` structures. It also emits a matcher for custom operand parsing. Extensive documentation is written on the ``AsmMatcherEmitter.cpp`` file. @@ -167,7 +167,7 @@ CallingConv conventions supported by this target. **Output**: Implement static functions to deal with calling conventions -chained by matching styles, returning false on no match. +chained by matching styles, returning ``false`` on no match. **Usage**: Used in ISelLowering and FastIsel as function pointers to implementation returned by a CC selection function. @@ -200,7 +200,7 @@ FastISel **Purpose**: This tablegen backend emits code for use by the "fast" instruction selection algorithm. See the comments at the top of -lib/CodeGen/SelectionDAG/FastISel.cpp for background. This file +``lib/CodeGen/SelectionDAG/FastISel.cpp`` for background. This file scans through the target's tablegen instruction-info files and extracts instructions with obvious-looking patterns, and it emits code to look up these instructions by type and operator. @@ -270,23 +270,23 @@ This file is included as part of ``Attr.h``. ClangAttrParserStringSwitches ----------------------------- -**Purpose**: Creates AttrParserStringSwitches.inc, which contains -StringSwitch::Case statements for parser-related string switches. Each switch +**Purpose**: Creates ``AttrParserStringSwitches.inc``, which contains +``StringSwitch::Case`` statements for parser-related string switches. Each switch is given its own macro (such as ``CLANG_ATTR_ARG_CONTEXT_LIST``, or ``CLANG_ATTR_IDENTIFIER_ARG_LIST``), which is expected to be defined before -including AttrParserStringSwitches.inc, and undefined after. +including ``AttrParserStringSwitches.inc``, and undefined after. ClangAttrImpl ------------- -**Purpose**: Creates AttrImpl.inc, which contains semantic attribute class +**Purpose**: Creates ``AttrImpl.inc``, which contains semantic attribute class definitions for any attribute in ``Attr.td`` that has not set ``ASTNode = 0``. This file is included as part of ``AttrImpl.cpp``. ClangAttrList ------------- -**Purpose**: Creates AttrList.inc, which is used when a list of semantic +**Purpose**: Creates ``AttrList.inc``, which is used when a list of semantic attribute identifiers is required. For instance, ``AttrKinds.h`` includes this file to generate the list of ``attr::Kind`` enumeration values. This list is separated out into multiple categories: attributes, inheritable attributes, and @@ -297,25 +297,25 @@ functionality required for ``dyn_cast`` and similar APIs. ClangAttrPCHRead ---------------- -**Purpose**: Creates AttrPCHRead.inc, which is used to deserialize attributes +**Purpose**: Creates ``AttrPCHRead.inc``, which is used to deserialize attributes in the ``ASTReader::ReadAttributes`` function. ClangAttrPCHWrite ----------------- -**Purpose**: Creates AttrPCHWrite.inc, which is used to serialize attributes in +**Purpose**: Creates ``AttrPCHWrite.inc``, which is used to serialize attributes in the ``ASTWriter::WriteAttributes`` function. ClangAttrSpellings --------------------- -**Purpose**: Creates AttrSpellings.inc, which is used to implement the +**Purpose**: Creates ``AttrSpellings.inc``, which is used to implement the ``__has_attribute`` feature test macro. ClangAttrSpellingListIndex -------------------------- -**Purpose**: Creates AttrSpellingListIndex.inc, which is used to map parsed +**Purpose**: Creates ``AttrSpellingListIndex.inc``, which is used to map parsed attribute spellings (including which syntax or scope was used) to an attribute spelling list index. These spelling list index values are internal implementation details exposed via @@ -324,26 +324,26 @@ implementation details exposed via ClangAttrVisitor ------------------- -**Purpose**: Creates AttrVisitor.inc, which is used when implementing +**Purpose**: Creates ``AttrVisitor.inc``, which is used when implementing recursive AST visitors. ClangAttrTemplateInstantiate ---------------------------- -**Purpose**: Creates AttrTemplateInstantiate.inc, which implements the +**Purpose**: Creates ``AttrTemplateInstantiate.inc``, which implements the ``instantiateTemplateAttribute`` function, used when instantiating a template that requires an attribute to be cloned. ClangAttrParsedAttrList ----------------------- -**Purpose**: Creates AttrParsedAttrList.inc, which is used to generate the +**Purpose**: Creates ``AttrParsedAttrList.inc``, which is used to generate the ``AttributeList::Kind`` parsed attribute enumeration. ClangAttrParsedAttrImpl ----------------------- -**Purpose**: Creates AttrParsedAttrImpl.inc, which is used by +**Purpose**: Creates ``AttrParsedAttrImpl.inc``, which is used by ``AttributeList.cpp`` to implement several functions on the ``AttributeList`` class. This functionality is implemented via the ``AttrInfoMap ParsedAttrInfo`` array, which contains one element per parsed attribute object. @@ -351,14 +351,14 @@ array, which contains one element per parsed attribute object. ClangAttrParsedAttrKinds ------------------------ -**Purpose**: Creates AttrParsedAttrKinds.inc, which is used to implement the +**Purpose**: Creates ``AttrParsedAttrKinds.inc``, which is used to implement the ``AttributeList::getKind`` function, mapping a string (and syntax) to a parsed attribute ``AttributeList::Kind`` enumeration. ClangAttrDump ------------- -**Purpose**: Creates AttrDump.inc, which dumps information about an attribute. +**Purpose**: Creates ``AttrDump.inc``, which dumps information about an attribute. It is used to implement ``ASTDumper::dumpAttr``. ClangDiagsDefs @@ -424,7 +424,7 @@ Generate list of commands that are used in documentation comments. ArmNeon ------- -Generate arm_neon.h for clang. +Generate ``arm_neon.h`` for clang. ArmNeonSema ----------- @@ -473,7 +473,7 @@ to a built-in backend. **Output**: -The root of the output file is a JSON object (i.e. dictionary), +The root of the output file is a JSON object (i.e., dictionary), containing the following fixed keys: * ``!tablegen_json_version``: a numeric version field that will @@ -520,7 +520,7 @@ conventions described below. Some TableGen data types are translated directly into the corresponding JSON type: -* A completely undefined value (e.g. for a variable declared without +* A completely undefined value (e.g., for a variable declared without initializer in some superclass of this record, and never initialized by the record itself or any other superclass) is emitted as the JSON ``null`` value. @@ -964,7 +964,7 @@ Here is the modified lookup function. The new lookup function will return an iterator range with first pointer to the first result and the last pointer to the last matching result from the table. -However, please note that the support for emitting modified definition exists +However, please note that the support for emitting a modified definition exists for ``PrimaryKeyName`` only. The ``PrimaryKeyEarlyOut`` field, when set to 1, modifies the lookup |