3 files changed, 15 insertions, 12 deletions
diff --git a/llvm/docs/CFIVerify.rst b/llvm/docs/CFIVerify.rst
index 6403347..f766be1 100644
--- a/llvm/docs/CFIVerify.rst
+++ b/llvm/docs/CFIVerify.rst
@@ -10,7 +10,7 @@ Objective
 
 This document provides an overview of an external tool to verify the protection
 mechanisms implemented by Clang's *Control Flow Integrity* (CFI) schemes
-(``-fsanitize=cfi``). This tool, provided a binary or DSO, should infer whether
+(``-fsanitize=cfi``). This tool, given a binary or DSO, should infer whether
 indirect control flow operations are protected by CFI, and should output these
 results in a human-readable form.
 
@@ -22,12 +22,12 @@ Location
 ========
 
 This tool will be present as a part of the LLVM toolchain, and will reside in
-the "/llvm/tools/llvm-cfi-verify" directory, relative to the LLVM trunk. It will
+the ``/llvm/tools/llvm-cfi-verify`` directory, relative to the LLVM trunk. It will
 be tested in two methods:
 
 - Unit tests to validate code sections, present in
-  "/llvm/unittests/tools/llvm-cfi-verify".
-- Integration tests, present in "/llvm/tools/clang/test/LLVMCFIVerify". These
+  ``/llvm/unittests/tools/llvm-cfi-verify``.
+- Integration tests, present in ``/llvm/tools/clang/test/LLVMCFIVerify``. These
   integration tests are part of clang as part of a continuous integration
   framework, ensuring updates to the compiler that reduce CFI coverage on
   indirect control flow instructions are identified.
@@ -38,16 +38,16 @@ Background
 This tool will continuously validate that CFI directives are properly
 implemented around all indirect control flows by analysing the output machine
 code. The analysis of machine code is important as it ensures that any bugs
-present in linker or compiler do not subvert CFI protections in the final
+present in the linker or compiler do not subvert CFI protections in the final
 shipped binary.
 
 Unprotected indirect control flow instructions will be flagged for manual
-review. These unexpected control flows may simply have not been accounted for in
-the compiler implementation of CFI (e.g. indirect jumps to facilitate switch
+review. These unexpected control flows may not have been accounted for in
+the compiler implementation of CFI (e.g., indirect jumps to facilitate switch
 statements may not be fully protected).
 
 It may be possible in the future to extend this tool to flag unnecessary CFI
-directives (e.g. CFI directives around a static call to a non-polymorphic base
+directives (e.g., CFI directives around a static call to a non-polymorphic base
 type). This type of directive has no security implications, but may present
 performance impacts.
 
@@ -66,7 +66,7 @@ the disassembly. A control flow graph would be generated from a small buffer of
 the instructions surrounding the 'target' control flow instruction. If the
 target instruction is branched-to, the fallthrough of the branch should be the
 CFI trap (on x86, this is a ``ud2`` instruction). If the target instruction is
-the fallthrough (i.e. immediately succeeds) of a conditional jump, the
+the fallthrough (i.e., immediately succeeds) of a conditional jump, the
 conditional jump target should be the CFI trap. If an indirect control flow
 instruction does not conform to one of these formats, the target will be noted
 as being CFI-unprotected.
@@ -76,7 +76,7 @@ fallthrough of a conditional jump), if the target represents a vcall that takes
 arguments, these arguments may be pushed to the stack after the branch but
 before the target instruction. In these cases, a secondary 'spill graph' in
 constructed, to ensure the register argument used by the indirect jump/call is
-not spilled from the stack at any point in the interim period. If there are no
+not spilled from the stack at any point in the interim. If there are no
 spills that affect the target register, the target is marked as CFI-protected.
 
 Other Design Notes
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 6d0e828..8b6c25c 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -8588,13 +8588,14 @@ functions, and contains richer semantic information about the type of the
 allocation. This information is consumed by the ``alloc-token`` pass to
 instrument such calls with allocation token IDs.
 
-The metadata contains a string with the type of an allocation.
+The metadata contains: string with the type of an allocation, and a boolean
+denoting if the type contains a pointer.
 
 .. code-block:: none
 
   call ptr @malloc(i64 64), !alloc_token !0
 
-  !0 = !{!"<type-name>"}
+  !0 = !{!"<type-name>", i1 <contains-pointer>}
 
 Module Flags Metadata
 =====================
diff --git a/llvm/docs/SPIRVUsage.rst b/llvm/docs/SPIRVUsage.rst
index b6cd4b4..d2d6646 100644
--- a/llvm/docs/SPIRVUsage.rst
+++ b/llvm/docs/SPIRVUsage.rst
@@ -233,6 +233,8 @@ Below is a list of supported SPIR-V extensions, sorted alphabetically by their e
      - Adds support for 4-bit integer type, and allow this type to be used in cooperative matrices.
    * - ``SPV_KHR_float_controls2``
      - 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.
 
 SPIR-V representation in LLVM IR
 ================================