[llvm-branch-commits] [llvm] [docs] Replace llvm.org/docs links with project links (PR #222506)
Reid Kleckner via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Mon Sep 14 15:49:19 PDT 2026
https://github.com/rnk updated https://github.com/llvm/llvm-project/pull/222506
>From 99baca36ed3401ea9af4905116e2d51e7461f407 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rkleckner at nvidia.com>
Date: Wed, 9 Sep 2026 22:51:11 +0000
Subject: [PATCH 1/3] [docs] Replace llvm.org/docs links with project links
Use Sphinx document and reference roles or project-relative links for
links within the LLVM documentation. This lets Sphinx validate the
targets and keeps local documentation builds and archived release
documentation self-contained.
Part of #214861
---
llvm/docs/AIToolPolicy.md | 2 +-
llvm/docs/AMDGPU/DeveloperGuideline.rst | 16 ++++++++--------
...cationDescriptionOnTheDwarfExpressionStack.md | 4 ++--
...UDwarfExtensionsForHeterogeneousDebugging.rst | 4 ++--
llvm/docs/AMDGPUUsage.rst | 3 +--
llvm/docs/AdminTasks.md | 2 +-
llvm/docs/BugLifeCycle.rst | 1 +
llvm/docs/CodeGenerator.md | 2 +-
llvm/docs/CodingStandards.md | 6 +++++-
llvm/docs/CommandGuide/llvm-ir2vec.md | 3 +--
llvm/docs/CommandGuide/llvm-remarkutil.md | 11 +++++------
llvm/docs/CompileCudaWithLLVM.md | 2 +-
llvm/docs/DeveloperPolicy.md | 2 +-
llvm/docs/GettingInvolved.md | 8 +++++---
llvm/docs/GettingStarted.md | 4 ++--
llvm/docs/GitHub.md | 2 +-
llvm/docs/GwpAsan.rst | 2 +-
llvm/docs/HowToAddABuilder.rst | 2 +-
llvm/docs/HowToBuildWithPGO.md | 2 +-
llvm/docs/HowToCrossCompileBuiltinsOnArm.md | 2 +-
llvm/docs/HowToCrossCompileLLVM.md | 5 ++---
llvm/docs/InstrProfileFormat.md | 4 ++--
llvm/docs/LangRef.md | 6 +++++-
llvm/docs/Lexicon.md | 2 +-
llvm/docs/LoopTerminology.md | 2 +-
llvm/docs/MIRLangRef.md | 2 +-
llvm/docs/MLGO.rst | 2 ++
llvm/docs/MeetupGuidelines.rst | 3 +--
llvm/docs/MemProf.md | 2 +-
llvm/docs/MergeFunctions.md | 12 ++++++------
llvm/docs/OpaquePointers.md | 2 +-
llvm/docs/PointerAuth.md | 6 +++---
llvm/docs/ProgrammersManual.md | 6 +++---
llvm/docs/Proposals/VectorPredication.rst | 2 +-
llvm/docs/QualGroup.rst | 2 +-
llvm/docs/RISCV/RISCVVectorExtension.md | 2 +-
llvm/docs/ReleaseNotes.md | 2 +-
llvm/docs/ScudoHardenedAllocator.rst | 3 +--
llvm/docs/Security.rst | 2 ++
llvm/docs/SecurityTransparencyReports.rst | 14 +++++++-------
llvm/docs/SupportPolicy.rst | 3 +--
llvm/docs/TestingGuide.md | 4 ++++
llvm/docs/tutorial/BuildingAJIT1.md | 5 ++---
llvm/docs/tutorial/BuildingAJIT4.md | 3 +--
.../MyFirstLanguageFrontend/LangImpl09.md | 3 +--
45 files changed, 94 insertions(+), 85 deletions(-)
diff --git a/llvm/docs/AIToolPolicy.md b/llvm/docs/AIToolPolicy.md
index c7576327b3262..eba9dfd2faa67 100644
--- a/llvm/docs/AIToolPolicy.md
+++ b/llvm/docs/AIToolPolicy.md
@@ -105,7 +105,7 @@ the industry. We therefore automatically post a greeting comment to pull
requests from new contributors and encourage maintainers to spend their time to
help new contributors learn.
-[commit-access]: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
+[commit-access]: project:DeveloperPolicy.md#obtaining-commit-access
## Handling Violations
diff --git a/llvm/docs/AMDGPU/DeveloperGuideline.rst b/llvm/docs/AMDGPU/DeveloperGuideline.rst
index c2fb5f58b6715..3c219cbd4a1ab 100644
--- a/llvm/docs/AMDGPU/DeveloperGuideline.rst
+++ b/llvm/docs/AMDGPU/DeveloperGuideline.rst
@@ -10,8 +10,8 @@ This document highlights coding conventions, test policies, and other
development guidelines that apply to all AMDGPU-related code across the LLVM
project (the backend in ``llvm/lib/Target/AMDGPU``, Clang AMDGPU support, LLD,
associated tests, etc.). It is **not** a replacement for or summary of the
-`LLVM Coding Standards <https://llvm.org/docs/CodingStandards.html>`_ or the
-`LLVM Testing Guide <https://llvm.org/docs/TestingGuide.html>`_; contributors
+:doc:`LLVM Coding Standards <../CodingStandards>` or the
+:doc:`LLVM Testing Guide <../TestingGuide>`; contributors
are expected to be familiar with those documents as well.
The topics covered here are those that come up frequently during AMDGPU code
@@ -22,14 +22,14 @@ Coding Standards
================
AMDGPU-related code follows the
-`LLVM Coding Standards <https://llvm.org/docs/CodingStandards.html>`_ with the
+:doc:`LLVM Coding Standards <../CodingStandards>` with the
refinements listed below.
Use of ``auto``
---------------
The LLVM Coding Standards describe the policy for ``auto`` in
-`Use auto Type Deduction to Make Code More Readable <https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>`_.
+:ref:`Use auto Type Deduction to Make Code More Readable <use-auto-type-deduction>`.
Below are more concrete examples of how that policy applies in AMDGPU code.
Do **not** use ``auto`` except in the following cases:
@@ -77,7 +77,7 @@ Use of Braces
-------------
The LLVM Coding Standards discuss brace usage in
-`Don't Use Braces on Simple Single-Statement Bodies of if/else/loop Statements <https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements>`_.
+:ref:`Don't Use Braces on Simple Single-Statement Bodies of if/else/loop Statements <don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements>`.
In AMDGPU code, braces may be omitted **only when the single statement
fits on one line**. If the statement spans more than one line (e.g. because of
a long argument list that wraps), keep the braces.
@@ -215,9 +215,9 @@ Test Policy
Well-written tests are essential for a healthy codebase. The guidelines below
apply to all AMDGPU regression tests (``llvm/test/CodeGen/AMDGPU``,
``llvm/test/MC/AMDGPU``, etc.). See also the general
-`Best practices for regression tests <https://llvm.org/docs/TestingGuide.html#best-practices-for-regression-tests>`_
+:ref:`Best practices for regression tests <best-practices-for-regression-tests>`
and the
-`Precommit workflow for tests <https://llvm.org/docs/TestingGuide.html#precommit-workflow-for-tests>`_
+:ref:`Precommit workflow for tests <precommit-workflow-for-tests>`
in the LLVM Testing Guide.
Use Minimal, Reduced Tests
@@ -234,7 +234,7 @@ Avoid Undefined Behavior
------------------------
Tests should not rely on undefined behavior (UB). As the
-`best practices section of the Testing Guide <https://llvm.org/docs/TestingGuide.html#best-practices-for-regression-tests>`_
+:ref:`best practices section of the Testing Guide <best-practices-for-regression-tests>`
notes, avoid ``undef`` and ``poison`` values unless they are the point of the
test - patterns like ``br i1 undef`` are likely to break as future
optimizations evolve.
diff --git a/llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md b/llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md
index f017672907a48..6b793efafb586 100644
--- a/llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md
+++ b/llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md
@@ -4012,8 +4012,8 @@ examples. It also covers other extensions needed for heterogeneous devices.
- [DWARF Debugging Information Format](https://dwarfstd.org/)
- [DWARF Debugging Information Format Version 5](https://dwarfstd.org/Dwarf5Std.php)
-- [Allow Location Descriptions on the DWARF Expression Stack](https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html)
+- {doc}`Allow Location Descriptions on the DWARF Expression Stack <AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack>`
- DWARF extensions for optimized SIMT/SIMD (GPU) debugging - Linux Plumbers Conference 2021
- [Video](https://www.youtube.com/watch?v=QiR0ra0ymEY&t=10015s)
- [Slides](https://linuxplumbersconf.org/event/11/contributions/1012/attachments/798/1505/DWARF_Extensions_for_Optimized_SIMT-SIMD_GPU_Debugging-LPC2021.pdf)
-- [DWARF Extensions For Heterogeneous Debugging](https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html)
+- {doc}`DWARF Extensions For Heterogeneous Debugging <../AMDGPUDwarfExtensionsForHeterogeneousDebugging>`
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
index ad4010c46de84..1c9685efddfe8 100644
--- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
+++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -5219,11 +5219,11 @@ D. References
.. _amdgpu-dwarf-AMDGPU-DWARF-LOC:
-4. [AMDGPU-DWARF-LOC] `Allow Location Descriptions on the DWARF Expression Stack <https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html>`__
+4. [AMDGPU-DWARF-LOC] :doc:`Allow Location Descriptions on the DWARF Expression Stack <AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack>`
.. _amdgpu-dwarf-AMDGPU-LLVM:
-5. [AMDGPU-LLVM] `User Guide for AMDGPU LLVM Backend <https://llvm.org/docs/AMDGPUUsage.html>`__
+5. [AMDGPU-LLVM] :doc:`User Guide for AMDGPU LLVM Backend <AMDGPUUsage>`
.. _amdgpu-dwarf-CUDA:
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index 0d1fcf0700122..efd26f04daa2e 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -956,8 +956,7 @@ Module Flags
------------
AMDGPU-specific behaviour can be controlled via LLVM module flags (see
-`Module Flags Metadata
-<https://llvm.org/docs/LangRef.html#module-flags-metadata>`_ in the language
+:ref:`Module Flags Metadata <module-flags-metadata>` in the language
reference). These flags are set by frontends and are
consumed by the AMDGPU backend during code generation.
diff --git a/llvm/docs/AdminTasks.md b/llvm/docs/AdminTasks.md
index 3e97b3fa5e0dd..9913322fc905a 100644
--- a/llvm/docs/AdminTasks.md
+++ b/llvm/docs/AdminTasks.md
@@ -14,7 +14,7 @@ If there are insufficient votes and it has been over two weeks since the last up
To reopen the request, someone with repository triage or write access must reapply the label to get it back on the dashboard.
[`infra:commit-access-request` label]: https://github.com/llvm/llvm-project/issues/?q=is%3Aissue%20state%3Aopen%20label%3Ainfra%3Acommit-access-request
-[commit access requirements]: https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
+[commit access requirements]: project:DeveloperPolicy.md#obtaining-commit-access
['LLVM Committers' team]: https://github.com/orgs/llvm/teams/llvm-committers
## Commit Access Review
diff --git a/llvm/docs/BugLifeCycle.rst b/llvm/docs/BugLifeCycle.rst
index 5f02f7c550f49..af3d607f95981 100644
--- a/llvm/docs/BugLifeCycle.rst
+++ b/llvm/docs/BugLifeCycle.rst
@@ -100,6 +100,7 @@ fixing it and to unassign it when you're no longer actively working on it. You
unassign a bug by removing the person from the ``Assignees`` field.
.. _Closing:
+.. _resolving-closing-bugs:
Resolving/Closing bugs
======================
diff --git a/llvm/docs/CodeGenerator.md b/llvm/docs/CodeGenerator.md
index 32242b413c2a8..82314a4570166 100644
--- a/llvm/docs/CodeGenerator.md
+++ b/llvm/docs/CodeGenerator.md
@@ -713,7 +713,7 @@ description (`*.td`) files. Our goal is for the entire instruction selector
to be generated from these `.td` files, though currently there are still
things that require custom C++ code.
-[GlobalISel](https://llvm.org/docs/GlobalISel/index.html) is another
+{doc}`GlobalISel <GlobalISel/index>` is another
instruction selection framework.
(SelectionDAG)=
diff --git a/llvm/docs/CodingStandards.md b/llvm/docs/CodingStandards.md
index 24df36285ba21..b5afe4b579443 100644
--- a/llvm/docs/CodingStandards.md
+++ b/llvm/docs/CodingStandards.md
@@ -106,7 +106,7 @@ subjects is available in the {doc}`ProgrammersManual`.
For more information about LLVM's data structures and the tradeoffs they make,
please consult [that section of the programmer's manual].
-[that section of the programmer's manual]: https://llvm.org/docs/ProgrammersManual.html#picking-the-right-data-structure-for-a-task
+[that section of the programmer's manual]: project:ProgrammersManual.md#picking-the-right-data-structure-for-a-task
### Python version and Source Code Formatting
@@ -755,6 +755,8 @@ If you use a braced initializer list when initializing a variable, use an equals
int data[] = {0, 1, 2, 3};
```
+(use-auto-type-deduction)=
+
#### Use `auto` Type Deduction to Make Code More Readable
Some are advocating a policy of "almost always `auto`" in C++11; however, LLVM
@@ -1712,6 +1714,8 @@ static void runHelper() {
}
```
+(don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements)=
+
#### Don't Use Braces on Simple Single-Statement Bodies of if/else/loop Statements
When writing the body of an `if`, `else`, or `for`/`while` loop
diff --git a/llvm/docs/CommandGuide/llvm-ir2vec.md b/llvm/docs/CommandGuide/llvm-ir2vec.md
index e5fb7ce989911..dba6b696b1ff2 100644
--- a/llvm/docs/CommandGuide/llvm-ir2vec.md
+++ b/llvm/docs/CommandGuide/llvm-ir2vec.md
@@ -36,7 +36,7 @@ instead of string triplets, streamlining the training data preparation workflow.
:::{note}
For information about using IR2Vec and MIR2Vec programmatically within LLVM
-passes and the C++ API, see the [IR2Vec Embeddings](https://llvm.org/docs/MLGO.html#ir2vec-embeddings)
+passes and the C++ API, see the [IR2Vec Embeddings](project:../MLGO.rst#ir2vec-embeddings)
section in the MLGO documentation.
:::
@@ -331,4 +331,3 @@ For more information about the IR2Vec algorithm and approach, see:
For more information about the MIR2Vec algorithm and approach, see:
[RL4ReAl: Reinforcement Learning for Register Allocation](https://doi.org/10.1145/3578360.3580273).
-
diff --git a/llvm/docs/CommandGuide/llvm-remarkutil.md b/llvm/docs/CommandGuide/llvm-remarkutil.md
index 5b0f150300d15..e17ce2a4f93fa 100644
--- a/llvm/docs/CommandGuide/llvm-remarkutil.md
+++ b/llvm/docs/CommandGuide/llvm-remarkutil.md
@@ -10,7 +10,7 @@
## Description
Utility for displaying information from, and converting between different
-[remark](https://llvm.org/docs/Remarks.html) formats.
+{doc}`remark <../Remarks>` formats.
## Subcommands
@@ -118,7 +118,7 @@ USAGE: {program}`llvm-remarkutil` count \[*options*\] \<input file>
#### Summary
-{program}`llvm-remarkutil count` counts [remarks](https://llvm.org/docs/Remarks.html) based on specified properties.
+{program}`llvm-remarkutil count` counts {doc}`remarks <../Remarks>` based on specified properties.
By default the tool counts remarks based on how many occur in a source file or function or total for the generated remark file.
The tool also supports collecting count based on specific remark arguments. The specified arguments should have an integer value to be able to report a count.
@@ -206,7 +206,7 @@ USAGE: {program}`llvm-remarkutil` size-diff \[*options*\] *file_a* *file_b* **--
#### Summary
-{program}`llvm-remarkutil size-diff` diffs size [remarks](https://llvm.org/docs/Remarks.html) in two remark files: `file_a`
+{program}`llvm-remarkutil size-diff` diffs size {doc}`remarks <../Remarks>` in two remark files: `file_a`
and `file_b`.
{program}`llvm-remarkutil size-diff` can be used to gain insight into which
@@ -217,8 +217,8 @@ compiling a **fixed source** with **differing compilers** or
**differing optimization settings**.
{program}`llvm-remarkutil size-diff` handles both
-[YAML](https://llvm.org/docs/Remarks.html#yaml-remarks) and
-[bitstream](https://llvm.org/docs/Remarks.html#llvm-bitstream-remarks)
+[YAML](project:../Remarks.md#yaml-remarks) and
+[bitstream](project:../Remarks.md#llvm-bitstream-remarks)
remarks.
#### Options
@@ -423,4 +423,3 @@ separately.
{program}`llvm-remarkutil size-diff` returns 0 on success, and a non-zero value
otherwise.
-
diff --git a/llvm/docs/CompileCudaWithLLVM.md b/llvm/docs/CompileCudaWithLLVM.md
index 6372987e1622f..5ec64e63ec7e1 100644
--- a/llvm/docs/CompileCudaWithLLVM.md
+++ b/llvm/docs/CompileCudaWithLLVM.md
@@ -558,4 +558,4 @@ Optimization (CGO 2016)*
## Obtaining Help
To obtain help on LLVM in general and its CUDA support, see [the LLVM
-community](https://llvm.org/docs/#mailing-lists).
+community](project:GettingInvolved.md#forums-mailing-lists).
diff --git a/llvm/docs/DeveloperPolicy.md b/llvm/docs/DeveloperPolicy.md
index 069b8fbb02798..d0e922cd22cd6 100644
--- a/llvm/docs/DeveloperPolicy.md
+++ b/llvm/docs/DeveloperPolicy.md
@@ -358,7 +358,7 @@ Below are some guidelines about the format of the message itself:
caused issue #".
- If the patch fixes a bug in GitHub Issues, we encourage adding a reference to
the issue being closed, as described
- [here](https://llvm.org/docs/BugLifeCycle.html#resolving-closing-bugs).
+ {ref}`here <resolving-closing-bugs>`.
- It is also acceptable to add other metadata to the commit message to automate
processes, including for downstream consumers. This metadata can include
links to resources that are not available to the entire community. However,
diff --git a/llvm/docs/GettingInvolved.md b/llvm/docs/GettingInvolved.md
index de5fe57cfdf7c..3ac6649ecdb15 100644
--- a/llvm/docs/GettingInvolved.md
+++ b/llvm/docs/GettingInvolved.md
@@ -169,7 +169,7 @@ what to add to your calendar invite.
- Monthly
-
- [Minutes/docs](https://docs.google.com/document/d/1JecbplF09l3swTjze-UVeLh4L48svJxGVy4mz_e9Rhs/edit?usp=gmail#heading=h.ts9cmcjbir1j)
- * - [LLVM security group](https://llvm.org/docs/Security.html)
+ * - {doc}`LLVM security group <Security>`
- Monthly, every 3rd Tuesday
- [ics](https://calendar.google.com/calendar/ical/eoh3m9k1l6vqbd1fkp94fv5q74%40group.calendar.google.com/public/basic.ics)
[gcal](https://calendar.google.com/calendar/embed?src=eoh3m9k1l6vqbd1fkp94fv5q74%40group.calendar.google.com)
@@ -219,7 +219,7 @@ what to add to your calendar invite.
- 3rd Tuesday of the month
- [ics](https://www.icloud.com/iclouddrive/032PeZzdN6U4uRMwJRJPrS2Lw#Vectorizer_Improvements)
- [Meeting details/agenda:](https://docs.google.com/document/d/1Glzy2JiWuysbD-HBWGUOkZqT09GJ4_Ljodr0lXD5XfQ/edit)
- * - [LLVM Qualification Working Group](https://llvm.org/docs/QualGroup.html)
+ * - {doc}`LLVM Qualification Working Group <QualGroup>`
- Monthly: 2nd Tuesday (EU/Asia) and 2nd Friday JST / Thursday (Americas)
- [ics](https://calendar.google.com/calendar/ical/f731f5b57956a132f6c553ed30f496b16e1018f831be13eb6c4b896c108a6626%40group.calendar.google.com/public/basic.ics)
[gcal](https://calendar.google.com/calendar/embed?src=f731f5b57956a132f6c553ed30f496b16e1018f831be13eb6c4b896c108a6626%40group.calendar.google.com&ctz=Asia%2FTokyo)
@@ -422,6 +422,8 @@ for info.
from the list above.
+(discord)=
+
## Discord
Users and developers of the LLVM project (including subprojects such as Clang)
@@ -591,7 +593,7 @@ This event is a meetup for all developers of LLDB. Meeting agendas are posted
on Discourse before the event.
Attendees must adhere to the LLVM Code of Conduct
-(https://llvm.org/docs/CodeOfConduct.html). For any Code of Conduct reports,
+({doc}`Code of Conduct <CodeOfConduct>`). For any Code of Conduct reports,
please contact the organizers and also email conduct at llvm.org.
Agenda/Meeting Minutes: Link to minutes
diff --git a/llvm/docs/GettingStarted.md b/llvm/docs/GettingStarted.md
index a8fb74dddd1b2..1e78ca5203be1 100644
--- a/llvm/docs/GettingStarted.md
+++ b/llvm/docs/GettingStarted.md
@@ -720,13 +720,13 @@ Generates system build files.
including a hand-written lexer, parser, AST, as well as code generation
support using LLVM- both static (ahead of time) and various approaches to
Just In Time (JIT) compilation.
- [Kaleidoscope Tutorial for complete beginner](https://llvm.org/docs/tutorial/MyFirstLanguageFrontend/index.html).
+ {doc}`Kaleidoscope Tutorial for complete beginner <tutorial/MyFirstLanguageFrontend/index>`.
- BuildingAJIT: Examples of the [BuildingAJIT tutorial] that shows how LLVM’s
ORC JIT APIs interact with other parts of LLVM. It also teaches how to
recombine them to build a custom JIT that is suited to your use-case.
-[BuildingAJIT tutorial]: https://llvm.org/docs/tutorial/BuildingAJIT1.html
+[BuildingAJIT tutorial]: project:tutorial/BuildingAJIT1.md
### `llvm/include`
diff --git a/llvm/docs/GitHub.md b/llvm/docs/GitHub.md
index 717cce12210fa..82c9c4354dac2 100644
--- a/llvm/docs/GitHub.md
+++ b/llvm/docs/GitHub.md
@@ -270,7 +270,7 @@ Your options are as follows:
perform this step using the web interface.
This approach requires commit access. See how to obtain it
- [here](https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access).
+ [here](project:DeveloperPolicy.md#obtaining-commit-access).
2. Two PRs with a dependency note
diff --git a/llvm/docs/GwpAsan.rst b/llvm/docs/GwpAsan.rst
index 65283fa115fb7..004f42aa60b78 100644
--- a/llvm/docs/GwpAsan.rst
+++ b/llvm/docs/GwpAsan.rst
@@ -119,7 +119,7 @@ Usage
=====
GWP-ASan already ships by default in the
-`Scudo Hardened Allocator <https://llvm.org/docs/ScudoHardenedAllocator.html>`_,
+:doc:`Scudo Hardened Allocator <ScudoHardenedAllocator>`,
so building with ``-fsanitize=scudo`` is the quickest and easiest way to try out
GWP-ASan.
diff --git a/llvm/docs/HowToAddABuilder.rst b/llvm/docs/HowToAddABuilder.rst
index bbc87e5841ddc..1714fe47744e0 100644
--- a/llvm/docs/HowToAddABuilder.rst
+++ b/llvm/docs/HowToAddABuilder.rst
@@ -133,7 +133,7 @@ Here are the steps you can follow to do so:
#. Send a patch which adds your build worker and your builder to
`zorg <https://github.com/llvm/llvm-zorg>`_. Use the typical LLVM
- `workflow <https://llvm.org/docs/Contributing.html#how-to-submit-a-patch>`_.
+ :ref:`workflow <submit_patch>`.
* workers are added to ``buildbot/osuosl/master/config/workers.py``
* builders are added to ``buildbot/osuosl/master/config/builders.py``
diff --git a/llvm/docs/HowToBuildWithPGO.md b/llvm/docs/HowToBuildWithPGO.md
index 421102a4f6cb9..30666695e2d1c 100644
--- a/llvm/docs/HowToBuildWithPGO.md
+++ b/llvm/docs/HowToBuildWithPGO.md
@@ -14,7 +14,7 @@ for PGO](https://clang.llvm.org/docs/UsersManual.html#profile-guided-optimizatio
## Using preconfigured CMake caches
-See <https://llvm.org/docs/AdvancedBuilds.html#multi-stage-pgo>
+See [Multi-stage PGO](project:AdvancedBuilds.md#multi-stage-pgo)
## Using the script
diff --git a/llvm/docs/HowToCrossCompileBuiltinsOnArm.md b/llvm/docs/HowToCrossCompileBuiltinsOnArm.md
index 7bcc86ffeb88a..85077d9ad84d9 100644
--- a/llvm/docs/HowToCrossCompileBuiltinsOnArm.md
+++ b/llvm/docs/HowToCrossCompileBuiltinsOnArm.md
@@ -37,7 +37,7 @@ In this example, we will be using `ninja` as the build tool.
See <https://compiler-rt.llvm.org/> for information about the dependencies
on clang and LLVM.
-See <https://llvm.org/docs/GettingStarted.html> for information about obtaining
+See {doc}`GettingStarted` for information about obtaining
the source for LLVM and compiler-rt.
`qemu-arm` should be available as a package for your Linux distribution.
diff --git a/llvm/docs/HowToCrossCompileLLVM.md b/llvm/docs/HowToCrossCompileLLVM.md
index 1712db50c1f5f..5dcaa333bf8d0 100644
--- a/llvm/docs/HowToCrossCompileLLVM.md
+++ b/llvm/docs/HowToCrossCompileLLVM.md
@@ -135,7 +135,7 @@ important:
for the target system into system directories for the host system. It is
not required unless you are going to use the `install` target.
-See [LLVM's build documentation](https://llvm.org/docs/CMake.html#frequently-used-cmake-variables) for more
+See [LLVM's build documentation](project:CMake.md#frequently-used-cmake-variables) for more
guidance on CMake variables (e.g. `LLVM_TARGETS_TO_BUILD` may be useful if
your cross-compiled binaries only need to support compiling for one target).
@@ -222,6 +222,5 @@ tar -czvf clang-$TARGET.tar.gz -C $HOME clang-$TARGET
The generated toolchain is portable, but requires compatible versions of any
shared libraries it links against. This means using a sysroot that is as
similar to your target operating system as possible is desirable. Other [CMake
-variables](https://llvm.org/docs/CMake.html#frequently-used-cmake-variables)
+variables](project:CMake.md#frequently-used-cmake-variables)
may be helpful, for instance `LLVM_STATIC_LINK_CXX_STDLIB`.
-
diff --git a/llvm/docs/InstrProfileFormat.md b/llvm/docs/InstrProfileFormat.md
index 336139fefd73f..6672d7ec10138 100644
--- a/llvm/docs/InstrProfileFormat.md
+++ b/llvm/docs/InstrProfileFormat.md
@@ -12,7 +12,7 @@ of interpretation across use cases, the documentation is based on IRPGO.
:::{note}
Frontend-generated profiles are used together with coverage mapping for
-[source-based code coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html). The [coverage mapping format](https://llvm.org/docs/CoverageMappingFormat.html) is different from
+[source-based code coverage](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html). The {doc}`coverage mapping format <CoverageMappingFormat>` is different from
profile format.
:::
@@ -457,7 +457,7 @@ human-readable way.
## Profile Data Usage
`llvm-profdata` is the command line tool to display and process instrumentation-
-based profile data. For supported usages, check out [llvm-profdata documentation](https://llvm.org/docs/CommandGuide/llvm-profdata.html).
+based profile data. For supported usages, check out {doc}`llvm-profdata documentation <CommandGuide/llvm-profdata>`.
[^1]: For usage, see https://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation
[^2]: For example, IR-based instrumentation supports [lightweight instrumentation]
diff --git a/llvm/docs/LangRef.md b/llvm/docs/LangRef.md
index 14caff88243c1..9a1c284a31ff8 100644
--- a/llvm/docs/LangRef.md
+++ b/llvm/docs/LangRef.md
@@ -167,6 +167,8 @@ depends on context.
## High Level Structure
+(modulestructure)=
+
### Module Structure
LLVM programs are composed of `Module`'s, each of which is a
@@ -2741,7 +2743,7 @@ fn -> other_fn -> other_fn ; fn is norecurse
`speculative_load_hardening`
: This attribute indicates that
- [Speculative Load Hardening](https://llvm.org/docs/SpeculativeLoadHardening.html)
+ {doc}`Speculative Load Hardening <SpeculativeLoadHardening>`
should be enabled for the function body.
Speculative Load Hardening is a best-effort mitigation against
@@ -9224,6 +9226,8 @@ This defines a global with type `SHT_LLVM_CFI_JUMP_TABLE` and entry
size 8.
+(module-flags-metadata)=
+
## Module Flags Metadata
Information about the module as a whole is difficult to convey to LLVM's
diff --git a/llvm/docs/Lexicon.md b/llvm/docs/Lexicon.md
index 022e9b5811f38..fc0e29c63a40a 100644
--- a/llvm/docs/Lexicon.md
+++ b/llvm/docs/Lexicon.md
@@ -123,7 +123,7 @@ This document is a work in progress!
**GEP**
: `GetElementPtr`. An LLVM IR instruction that is used to get the address
of a subelement of an aggregate data structure. It is documented in detail
- [here](https://llvm.org/docs/GetElementPtr.html).
+ {doc}`here <GetElementPtr>`.
**GVN**
: Global Value Numbering. GVN is a pass that partitions values computed by a
diff --git a/llvm/docs/LoopTerminology.md b/llvm/docs/LoopTerminology.md
index ffdf6778d397b..fd488e4570dc7 100644
--- a/llvm/docs/LoopTerminology.md
+++ b/llvm/docs/LoopTerminology.md
@@ -347,7 +347,7 @@ will be deleted by {ref}`-instcombine <passes-instcombine>`.
Note that an exit block is outside of a loop, so how can such a phi "close"
the value inside the loop since it uses it outside of it ? First of all,
for phi nodes, as
-[mentioned in the LangRef](https://llvm.org/docs/LangRef.html#phi-instruction):
+[mentioned in the LangRef](project:LangRef.md#phi-instruction):
"the use of each incoming value is deemed to occur on the edge from the
corresponding predecessor block to the current block". Now, an
edge to an exit block is considered outside of the loop because
diff --git a/llvm/docs/MIRLangRef.md b/llvm/docs/MIRLangRef.md
index a767d6e2ee239..85ee40593bc43 100644
--- a/llvm/docs/MIRLangRef.md
+++ b/llvm/docs/MIRLangRef.md
@@ -577,7 +577,7 @@ constants:
where:
- `<index>` is a 32-bit unsigned integer;
- - `<value>` is a [LLVM IR Constant](https://www.llvm.org/docs/LangRef.html#constants);
+ - `<value>` is a [LLVM IR Constant](project:LangRef.md#constants);
- `<alignment>` is a 32-bit unsigned integer specified in bytes, and must be
power of two;
- `<target-specific>` is either true or false.
diff --git a/llvm/docs/MLGO.rst b/llvm/docs/MLGO.rst
index 8f8a35d5e2693..7221175446abc 100644
--- a/llvm/docs/MLGO.rst
+++ b/llvm/docs/MLGO.rst
@@ -452,6 +452,8 @@ point vectors. These embeddings can be computed at multiple granularity levels
(instruction, basic block, and function) and used for ML-guided compiler
optimizations.
+.. _ir2vec-embeddings:
+
IR2Vec
------
diff --git a/llvm/docs/MeetupGuidelines.rst b/llvm/docs/MeetupGuidelines.rst
index 493593eadfb5f..4f180bc2ec945 100644
--- a/llvm/docs/MeetupGuidelines.rst
+++ b/llvm/docs/MeetupGuidelines.rst
@@ -7,7 +7,7 @@ LLVM Social.
Before you start, it is essential to make sure that the meetup is as welcoming
as any other event related to LLVM. Therefore you shall follow LLVM's
-`Code of Conduct <https://llvm.org/docs/CodeOfConduct.html>`_.
+:doc:`Code of Conduct <CodeOfConduct>`.
Other than that - your mileage may vary. Please adapt your social to what works
best for your specific situation.
@@ -79,4 +79,3 @@ How to pick the date?
but the people who live in the city may not attend.
* Make a poll, but beware that not every responder will join (we had ~20 votes
on the poll, while only ~8 people attended).
-
diff --git a/llvm/docs/MemProf.md b/llvm/docs/MemProf.md
index d292a259650a3..d1e8dac1ed03a 100644
--- a/llvm/docs/MemProf.md
+++ b/llvm/docs/MemProf.md
@@ -81,7 +81,7 @@ If invoking the optimizer directly via `opt`:
opt -passes='memprof-use<profile-filename=memprof.memprofdata>' ...
```
-The compiler uses the profile data to annotate allocation instructions with `!memprof` metadata ([MemProf Metadata Documentation](https://llvm.org/docs/LangRef.html#memprof-metadata)), distinguishing between "hot", "cold", and "notcold" allocations. This metadata guides downstream optimizations. Additionally, callsites which are part of allocation contexts are also annotated with `!callsite` metadata ([Callsite Metadata Documentation](https://llvm.org/docs/LangRef.html#callsite-metadata)).
+The compiler uses the profile data to annotate allocation instructions with `!memprof` metadata ([MemProf Metadata Documentation](project:LangRef.md#memprof-metadata)), distinguishing between "hot", "cold", and "notcold" allocations. This metadata guides downstream optimizations. Additionally, callsites which are part of allocation contexts are also annotated with `!callsite` metadata ([Callsite Metadata Documentation](project:LangRef.md#callsite-metadata)).
:::{note}
Ensure that the same debug info flags (e.g. `-gmlt` and `-fdebug-info-for-profiling`) used during instrumentation are also passed during this compilation step to enable correct matching of the profile data.
diff --git a/llvm/docs/MergeFunctions.md b/llvm/docs/MergeFunctions.md
index adc8bcec7c5d4..b826b55844880 100644
--- a/llvm/docs/MergeFunctions.md
+++ b/llvm/docs/MergeFunctions.md
@@ -32,15 +32,15 @@ The reader should be familiar with common compiler-engineering principles and
LLVM code fundamentals. In this article, we assume the reader is familiar with
[Single Static Assignment](http://en.wikipedia.org/wiki/Static_single_assignment_form)
concept and has an understanding of
-[IR structure](https://llvm.org/docs/LangRef.html#high-level-structure).
+[IR structure](project:LangRef.md#high-level-structure).
We will use terms such as
-"[module](https://llvm.org/docs/LangRef.html#high-level-structure)",
-"[function](https://llvm.org/docs/ProgrammersManual.html#the-function-class)",
+"[module](project:LangRef.md#high-level-structure)",
+"[function](project:ProgrammersManual.md#the-function-class)",
"[basic block](http://en.wikipedia.org/wiki/Basic_block)",
-"[user](https://llvm.org/docs/ProgrammersManual.html#the-user-class)",
-"[value](https://llvm.org/docs/ProgrammersManual.html#the-value-class)",
-"[instruction](https://llvm.org/docs/ProgrammersManual.html#the-instruction-class)".
+"[user](project:ProgrammersManual.md#the-user-class)",
+"[value](project:ProgrammersManual.md#the-value-class)",
+"[instruction](project:ProgrammersManual.md#the-instruction-class)".
As a good starting point, the Kaleidoscope tutorial can be used:
diff --git a/llvm/docs/OpaquePointers.md b/llvm/docs/OpaquePointers.md
index f455806dfde02..59c7a23605796 100644
--- a/llvm/docs/OpaquePointers.md
+++ b/llvm/docs/OpaquePointers.md
@@ -58,7 +58,7 @@ optimization. Memory optimization algorithms, such as SROA, GVN, and AA,
generally need to look through LLVM's struct types and reason about the
underlying memory offsets. The community realized that pointee types hinder LLVM
development, rather than helping it. Some of the initially proposed high-level
-optimizations have evolved into [TBAA](https://llvm.org/docs/LangRef.html#tbaa-metadata) due to limitations with
+optimizations have evolved into [TBAA](project:LangRef.md#tbaa-metadata) due to limitations with
representing higher-level language information directly via SSA values.
Pointee types provide some value to frontends because the IR verifier uses types
diff --git a/llvm/docs/PointerAuth.md b/llvm/docs/PointerAuth.md
index 84e0af7577c7d..62e0d3a2353d9 100644
--- a/llvm/docs/PointerAuth.md
+++ b/llvm/docs/PointerAuth.md
@@ -236,7 +236,7 @@ in code, but not for signed pointers referenced by constants, in, e.g., global
initializers.
The latter are represented using a
-[``ptrauth`` constant](https://llvm.org/docs/LangRef.html#ptrauth-constant),
+{ref}`ptrauth constant <ptrauth_constant>`,
which describes an authenticated relocation producing a signed pointer.
```llvm
@@ -299,8 +299,8 @@ operations that are not otherwise explicitly expressed in IR.
``ptrauth-indirect-gotos`` specifies that indirect gotos in this function
should authenticate their target. At the IR level, no other change is needed.
-When lowering [``blockaddress`` constants](https://llvm.org/docs/LangRef.html#blockaddress),
-and [``indirectbr`` instructions](https://llvm.org/docs/LangRef.html#i-indirectbr),
+When lowering {ref}`blockaddress constants <blockaddress>`,
+and {ref}`indirectbr instructions <i_indirectbr>`,
this tells the backend to respectively sign and authenticate the pointers.
The specific scheme isn't ABI-visible. Currently, the AArch64 backend
diff --git a/llvm/docs/ProgrammersManual.md b/llvm/docs/ProgrammersManual.md
index 0deb31426597a..db02e8ace49b1 100644
--- a/llvm/docs/ProgrammersManual.md
+++ b/llvm/docs/ProgrammersManual.md
@@ -1375,8 +1375,8 @@ but when it is done, it will print the result like: `Minimal Chunks = 0:1:5:11-1
Several of the important data structures in LLVM are graphs: for example CFGs
made out of LLVM {ref}`BasicBlocks <BasicBlock>`, CFGs made out of LLVM
-[MachineBasicBlocks](https://llvm.org/docs/CodeGenerator.html#machinebasicblock), and [Instruction Selection
-DAGs](https://llvm.org/docs/CodeGenerator.html#selectiondag). In many cases, while debugging various parts of the
+{ref}`MachineBasicBlocks <MachineBasicBlock>`, and {ref}`Instruction Selection
+DAGs <SelectionDAG>`. In many cases, while debugging various parts of the
compiler, it is nice to instantly visualize these graphs.
LLVM provides several callbacks that are available in a debug build to do
@@ -3925,7 +3925,7 @@ runtime).
the resultant global variable will have internal linkage. AppendingLinkage
concatenates together all instances (in different translation units) of the
variable into a single variable but is only applicable to arrays. See the
- [LLVM Language Reference](https://llvm.org/docs/LangRef.html#modulestructure) for further details
+ {ref}`LLVM Language Reference <modulestructure>` for further details
on linkage types. Optionally an initializer, a name, and the module to put
the variable into may be specified for the global variable as well.
diff --git a/llvm/docs/Proposals/VectorPredication.rst b/llvm/docs/Proposals/VectorPredication.rst
index 8fa6f92f425b8..6a47d17851690 100644
--- a/llvm/docs/Proposals/VectorPredication.rst
+++ b/llvm/docs/Proposals/VectorPredication.rst
@@ -79,7 +79,7 @@ References
==========
.. [MaskedIR] `llvm.masked.*` intrinsics,
- https://llvm.org/docs/LangRef.html#masked-vector-load-and-store-intrinsics
+ :ref:`masked vector load and store intrinsics <int_mload_mstore>`
.. [VPRFC] RFC: Prototype & Roadmap for vector predication in LLVM,
https://reviews.llvm.org/D57504
diff --git a/llvm/docs/QualGroup.rst b/llvm/docs/QualGroup.rst
index e2efa6d60490e..0578f64444834 100644
--- a/llvm/docs/QualGroup.rst
+++ b/llvm/docs/QualGroup.rst
@@ -96,7 +96,7 @@ Participation
There are several ways to participate:
* Join discussions on the `LLVM Discourse <https://discourse.llvm.org/>`_ forum, under the "Community" category.
-* Engage in conversations on the LLVM Community Discord in the `#fusa-qual-wg <https://discord.com/channels/636084430946959380/1389362444169773117>`_ channel. Note: You need to join the community's `Discord chat server <https://llvm.org/docs/GettingInvolved.html#discord>`_ first.
+* Engage in conversations on the LLVM Community Discord in the `#fusa-qual-wg <https://discord.com/channels/636084430946959380/1389362444169773117>`_ channel. Note: You need to join the community's :ref:`Discord chat server <discord>` first.
* Join our monthly sync-up calls. Details on working sessions and meeting minutes are shared on the :doc:`GettingInvolved` page.
* Contribute ideas, feedback, or patches via GitHub, Discourse, or directly in working documents.
diff --git a/llvm/docs/RISCV/RISCVVectorExtension.md b/llvm/docs/RISCV/RISCVVectorExtension.md
index 03eb27838b913..79f2521dd5407 100644
--- a/llvm/docs/RISCV/RISCVVectorExtension.md
+++ b/llvm/docs/RISCV/RISCVVectorExtension.md
@@ -5,7 +5,7 @@ This guide gives an overview of how it's modelled in LLVM IR and how the backend
## Mapping to LLVM IR types
-RVV adds 32 VLEN sized registers, where VLEN is an unknown constant to the compiler. To be able to represent VLEN sized values, the RISC-V backend takes the same approach as AArch64's SVE and uses [scalable vector types](https://llvm.org/docs/LangRef.html#t-vector).
+RVV adds 32 VLEN sized registers, where VLEN is an unknown constant to the compiler. To be able to represent VLEN sized values, the RISC-V backend takes the same approach as AArch64's SVE and uses {ref}`scalable vector types <t_vector>`.
Scalable vector types are of the form `<vscale x n x ty>`, which indicates a vector with a multiple of `n` elements of type `ty`.
On RISC-V `n` and `ty` control LMUL and SEW respectively.
diff --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md
index 4718d47bf8c10..df653ebbb8a72 100644
--- a/llvm/docs/ReleaseNotes.md
+++ b/llvm/docs/ReleaseNotes.md
@@ -320,7 +320,7 @@ Makes programs 10x faster by doing Special New Thing.
A wide variety of additional information is available on the
[LLVM web page](https://llvm.org/), in particular in the
-[documentation](https://llvm.org/docs/) section. The web page also contains
+{doc}`documentation <index>` section. The web page also contains
versions of the API documentation which is up-to-date with the Git version of
the source code. You can access versions of these documents specific to this
release by going into the `llvm/docs/` directory in the LLVM tree.
diff --git a/llvm/docs/ScudoHardenedAllocator.rst b/llvm/docs/ScudoHardenedAllocator.rst
index 7ac6522f90a49..189b422260d0b 100644
--- a/llvm/docs/ScudoHardenedAllocator.rst
+++ b/llvm/docs/ScudoHardenedAllocator.rst
@@ -266,7 +266,7 @@ The following "string" options are available:
+---------------------------------+----------------+-------------------------------------------------+
Additional flags can be specified, for example if Scudo if compiled with
-`GWP-ASan <https://llvm.org/docs/GwpAsan.html>`_ support.
+:doc:`GWP-ASan <GwpAsan>` support.
The following "mallopt" options are available (options are defined in
``include/scudo/interface.h``):
@@ -358,4 +358,3 @@ Here is a list of the current error messages and their potential cause:
Several other error messages relate to parameter checking on the libc allocation
APIs and are fairly straightforward to understand.
-
diff --git a/llvm/docs/Security.rst b/llvm/docs/Security.rst
index 9c586437d25c1..7325b4fe541d9 100644
--- a/llvm/docs/Security.rst
+++ b/llvm/docs/Security.rst
@@ -201,6 +201,8 @@ Changes to the Policy
The LLVM Security Policy may be changed by majority vote of the LLVM Security Response Group. Such changes also need to be approved by the LLVM Board.
+.. _what-is-considered-a-security-issue:
+
What is considered a security issue?
====================================
diff --git a/llvm/docs/SecurityTransparencyReports.rst b/llvm/docs/SecurityTransparencyReports.rst
index 711e6d8ae6b88..58a753e252b97 100644
--- a/llvm/docs/SecurityTransparencyReports.rst
+++ b/llvm/docs/SecurityTransparencyReports.rst
@@ -58,8 +58,8 @@ We believe that with the publishing of this first annual transparency report,
the security group now has implemented all necessary processes for the group to
operate as promised. The group's processes can be improved further, and we do
expect further improvements to get implemented in 2022. Many of the potential
-improvements end up being discussed on the `monthly public call on LLVM's
-security group <https://llvm.org/docs/GettingInvolved.html#online-sync-ups>`_.
+improvements end up being discussed on the :doc:`monthly public call on LLVM's
+security group <GettingInvolved>`.
2022
@@ -425,20 +425,20 @@ Issues deemed to not require coordinated action before disclosing publicly
`GHSA-m967-6j3p-jrwc <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-m967-6j3p-jrwc>`_ |br|
There has been an agreement that the proof of concept had undefined
behavior which makes it out of scope according to
- `the LLVM threat model <https://llvm.org/docs/Security.html#what-is-considered-a-security-issue>`_.
+ :ref:`the LLVM threat model <what-is-considered-a-security-issue>`.
3. “\[clangd\] heap-use-after-free in clangd when generating diagnostics” |br|
Details are available at
`GHSA-5426-9r4h-7whf <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-5426-9r4h-7whf>`_ |br|
It has been agreed this report fell out of scope because it was caused by
untrusted inputs, as described in
- `the LLVM threat model <https://llvm.org/docs/Security.html#what-is-considered-a-security-issue>`_.
+ :ref:`the LLVM threat model <what-is-considered-a-security-issue>`.
4. “A compiler optimization bug may cause signed integer overflow detection
be bypassed” |br|
Details are available at
`GHSA-w6jm-h8j9-q33r <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-w6jm-h8j9-q33r>`_ |br|
There has been an agreement that the PoC had undefined behavior which makes
it out of scope according to
- `the LLVM threat model <https://llvm.org/docs/Security.html#what-is-considered-a-security-issue>`_.
+ :ref:`the LLVM threat model <what-is-considered-a-security-issue>`.
5. “libomp: Crash (OOB Write / ASan BUS Error) involving omp\_init\_lock under
high concurrency” |br|
Details are available at
@@ -451,12 +451,12 @@ Issues deemed to not require coordinated action before disclosing publicly
`GHSA-8j9r-qc4r-q9fh <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-8j9r-qc4r-q9fh>`_ |br|
This report fell out of scope because it was caused by untrusted inputs,
as described in
- `the LLVM threat model <https://llvm.org/docs/Security.html#what-is-considered-a-security-issue>`_.
+ :ref:`the LLVM threat model <what-is-considered-a-security-issue>`.
7. “\[clangd/clang\] heap-buffer-overflow in clang/lib/Sema/SemaExprCXX.cpp:9144” |br|
Details are available at
`GHSA-qq8q-r524-8vw9 <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-qq8q-r524-8vw9>`_ |br|
This issue and the following 3 were concluded to be outside of the
- `LLVM threat model <https://llvm.org/docs/Security.html#what-is-considered-a-security-issue>`_.
+ :ref:`LLVM threat model <what-is-considered-a-security-issue>`.
8. “\[clangd\] heap-buffer-overflow in clang/lib/Sema/SemaExprCXX.cpp:8876” |br|
Details are available at
`GHSA-3xm9-vccr-fxx5 <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-3xm9-vccr-fxx5>`_
diff --git a/llvm/docs/SupportPolicy.rst b/llvm/docs/SupportPolicy.rst
index 0766522a9c578..f9c14100a801f 100644
--- a/llvm/docs/SupportPolicy.rst
+++ b/llvm/docs/SupportPolicy.rst
@@ -81,7 +81,7 @@ It is the responsibility of each sub-community to care about their own parts
and the intersection of that with the core tier and other peripheral parts.
There are three main groups of code that fit in this category:
- * Code that is making its way into LLVM, via the `experimental <https://llvm.org/docs/DeveloperPolicy.html#introducing-new-components-into-llvm>`_
+ * Code that is making its way into LLVM, via the :ref:`experimental <new-llvm-components>`
roadmap or similar efforts.
* Code that is making its way out of LLVM, via deprecation, replacement or
bit-rot, and will be removed if the sub-community that cares about it
@@ -239,4 +239,3 @@ overall maintenance costs to a minimum and will need to show steps to mitigate
all of the issues that were listed as reasons for its original removal.
Failing on those again, will lead to become a candidate for removal yet again.
-
diff --git a/llvm/docs/TestingGuide.md b/llvm/docs/TestingGuide.md
index f3017993d781d..77803c4443da2 100644
--- a/llvm/docs/TestingGuide.md
+++ b/llvm/docs/TestingGuide.md
@@ -319,6 +319,8 @@ update_llubi_test_checks.py
llubi
```
+(precommit-workflow-for-tests)=
+
### Precommit workflow for tests
If the test does not crash, assert, or infinite loop, commit the test with
@@ -333,6 +335,8 @@ Remove TODO/FIXME comments added in the previous step if a problem is solved.
Baseline tests (no-functional-change or NFC patch) may be pushed to main
without pre-commit review if you have commit access.
+(best-practices-for-regression-tests)=
+
### Best practices for regression tests
- Use auto-generated check lines (produced by the scripts mentioned above)
diff --git a/llvm/docs/tutorial/BuildingAJIT1.md b/llvm/docs/tutorial/BuildingAJIT1.md
index 7add8d3ecc95f..72435a774efce 100644
--- a/llvm/docs/tutorial/BuildingAJIT1.md
+++ b/llvm/docs/tutorial/BuildingAJIT1.md
@@ -33,7 +33,7 @@ The structure of the tutorial is:
replacing the Compile-On-Demand layer with a custom layer that uses the ORC
Compile Callbacks API directly to defer IR-generation until functions are
called.
-- [Chapter #5](https://llvm.org/docs/tutorial/BuildingAJIT5.html): Add process isolation by JITing code into
+- Chapter #5: Add process isolation by JITing code into
a remote process with reduced privileges using the JIT Remote APIs.
To provide input for our JIT we will use a lightly modified version of the
@@ -292,5 +292,4 @@ Here is the code:
| LLVMContext.h | Provides the LLVMContext class. |
[^footnote-3]: See the ErrorHandling section in the LLVM Programmer's Manual
- (<https://llvm.org/docs/ProgrammersManual.html#error-handling>)
-
+ ([Error handling](project:../ProgrammersManual.md#error-handling))
diff --git a/llvm/docs/tutorial/BuildingAJIT4.md b/llvm/docs/tutorial/BuildingAJIT4.md
index fd3d4d6950046..957b3d5fb714a 100644
--- a/llvm/docs/tutorial/BuildingAJIT4.md
+++ b/llvm/docs/tutorial/BuildingAJIT4.md
@@ -39,5 +39,4 @@ Here is the code:
:language: c++
```
-[Next: Remote-JITing -- Process-isolation and laziness-at-a-distance](https://llvm.org/docs/tutorial/BuildingAJIT5.html)
-
+Next: Remote-JITing -- Process-isolation and laziness-at-a-distance
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.md b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.md
index cd2b9fbe4fbd4..9db3191343796 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.md
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl09.md
@@ -160,7 +160,7 @@ corresponds 1:1 similarly to `IRBuilder` and LLVM IR, but with nicer names.
Using it does require that you be more familiar with DWARF terminology than
you needed to be with `IRBuilder` and `Instruction` names, but if you
read through the general documentation on the
-[Metadata Format](https://llvm.org/docs/SourceLevelDebugging.html) it
+{doc}`Metadata Format <../../SourceLevelDebugging>` it
should be a little more clear. We'll be using this class to construct all
of our IR level descriptions. Construction for it takes a module so we
need to construct it shortly after we construct our module. We've left it
@@ -450,4 +450,3 @@ Here is the code:
```
[Next: Conclusion and other useful LLVM tidbits](LangImpl10.md)
-
>From fcf49171f12b79b193c87065c29440291df965b3 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rkleckner at nvidia.com>
Date: Fri, 11 Sep 2026 21:07:32 +0000
Subject: [PATCH 2/3] [docs] Repair stale LLVM documentation links
Use the Sphinx ref role for the IR2Vec section label so clean Sphinx
builds resolve it correctly. Remove the dangling BuildingAJIT Chapter 5
navigation text because that chapter no longer exists.
Fixes follow-up issues in #222506.
---
llvm/docs/CommandGuide/llvm-ir2vec.md | 2 +-
llvm/docs/tutorial/BuildingAJIT4.md | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/llvm/docs/CommandGuide/llvm-ir2vec.md b/llvm/docs/CommandGuide/llvm-ir2vec.md
index dba6b696b1ff2..c9f4819f69e95 100644
--- a/llvm/docs/CommandGuide/llvm-ir2vec.md
+++ b/llvm/docs/CommandGuide/llvm-ir2vec.md
@@ -36,7 +36,7 @@ instead of string triplets, streamlining the training data preparation workflow.
:::{note}
For information about using IR2Vec and MIR2Vec programmatically within LLVM
-passes and the C++ API, see the [IR2Vec Embeddings](project:../MLGO.rst#ir2vec-embeddings)
+passes and the C++ API, see the {ref}`IR2Vec Embeddings <ir2vec-embeddings>`
section in the MLGO documentation.
:::
diff --git a/llvm/docs/tutorial/BuildingAJIT4.md b/llvm/docs/tutorial/BuildingAJIT4.md
index 957b3d5fb714a..6b61885967bf1 100644
--- a/llvm/docs/tutorial/BuildingAJIT4.md
+++ b/llvm/docs/tutorial/BuildingAJIT4.md
@@ -38,5 +38,3 @@ Here is the code:
```{literalinclude} ../../examples/Kaleidoscope/BuildingAJIT/Chapter4/KaleidoscopeJIT.h
:language: c++
```
-
-Next: Remote-JITing -- Process-isolation and laziness-at-a-distance
>From 7878c7d85e34dd001c49c154f45a14611df7c081 Mon Sep 17 00:00:00 2001
From: Reid Kleckner <rkleckner at nvidia.com>
Date: Mon, 14 Sep 2026 22:48:22 +0000
Subject: [PATCH 3/3] revert whitespace change
---
llvm/docs/CommandGuide/llvm-ir2vec.md | 1 +
1 file changed, 1 insertion(+)
diff --git a/llvm/docs/CommandGuide/llvm-ir2vec.md b/llvm/docs/CommandGuide/llvm-ir2vec.md
index c9f4819f69e95..f6312152de8f3 100644
--- a/llvm/docs/CommandGuide/llvm-ir2vec.md
+++ b/llvm/docs/CommandGuide/llvm-ir2vec.md
@@ -331,3 +331,4 @@ For more information about the IR2Vec algorithm and approach, see:
For more information about the MIR2Vec algorithm and approach, see:
[RL4ReAl: Reinforcement Learning for Register Allocation](https://doi.org/10.1145/3578360.3580273).
+
More information about the llvm-branch-commits
mailing list