diff options
Diffstat (limited to 'llvm/docs')
35 files changed, 256 insertions, 240 deletions
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst index 95ae4f7..ba670d3 100644 --- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst +++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst @@ -1187,7 +1187,7 @@ There are five kinds of location storage: operations. It would specify the debugger information entry and byte offset provided by the operations. -*Location descriptions are a language independent representation of addressing +*Location descriptions are a language-independent representation of addressing rules.* * *They can be the result of evaluating a debugger information entry attribute @@ -1523,8 +1523,8 @@ expression. states that relocation of references from one executable or shared object file to another must be performed by the consumer. But given that DR is defined as an offset in a ``.debug_info`` section this seems impossible. - If DR was defined as an implementation defined value, then the consumer - could choose to interpret the value in an implementation defined manner to + If DR was defined as an implementation-defined value, then the consumer + could choose to interpret the value in an implementation-defined manner to reference a debug information in another executable or shared object. In ELF the ``.debug_info`` section is in a non-\ ``PT_LOAD`` segment so @@ -4188,7 +4188,7 @@ The register rules are: conversion as the bit contents of the register is simply interpreted as a value of the address. - GDB has a per register hook that allows a target specific conversion on a + GDB has a per register hook that allows a target-specific conversion on a register by register basis. It defaults to truncation of bigger registers, and to actually reading bytes from the next register (or reads out of bounds for the last register) for smaller registers. There are no GDB tests that diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst index c3d4833..5343d66 100644 --- a/llvm/docs/AMDGPUUsage.rst +++ b/llvm/docs/AMDGPUUsage.rst @@ -1890,7 +1890,7 @@ The AMDGPU backend supports the following calling conventions: AMDGPU MCExpr ------------- -As part of the AMDGPU MC layer, AMDGPU provides the following target specific +As part of the AMDGPU MC layer, AMDGPU provides the following target-specific ``MCExpr``\s. .. table:: AMDGPU MCExpr types: diff --git a/llvm/docs/CodeGenerator.rst b/llvm/docs/CodeGenerator.rst index 020eb09..8260b5c 100644 --- a/llvm/docs/CodeGenerator.rst +++ b/llvm/docs/CodeGenerator.rst @@ -323,7 +323,7 @@ provide one of these objects through the ``getJITInfo`` method. Machine code description classes ================================ -At the high-level, LLVM code is translated to a machine specific representation +At the high-level, LLVM code is translated to a machine-specific representation formed out of :raw-html:`<tt>` `MachineFunction`_ :raw-html:`</tt>`, :raw-html:`<tt>` `MachineBasicBlock`_ :raw-html:`</tt>`, and :raw-html:`<tt>` `MachineInstr`_ :raw-html:`</tt>` instances (defined in @@ -462,7 +462,7 @@ code: ret This approach is extremely general (if it can handle the X86 architecture, it -can handle anything!) and allows all of the target specific knowledge about the +can handle anything!) and allows all of the target-specific knowledge about the instruction stream to be isolated in the instruction selector. Note that physical registers should have a short lifetime for good code generation, and all physical registers are assumed dead on entry to and exit from basic blocks @@ -634,7 +634,7 @@ file (MCObjectStreamer). MCAsmStreamer is a straightforward implementation that prints out a directive for each method (e.g. ``EmitValue -> .byte``), but MCObjectStreamer implements a full assembler. -For target specific directives, the MCStreamer has a MCTargetStreamer instance. +For target-specific directives, the MCStreamer has a MCTargetStreamer instance. Each target that needs it defines a class that inherits from it and is a lot like MCStreamer itself: It has one method per directive and two classes that inherit from it, a target object streamer and a target asm streamer. The target diff --git a/llvm/docs/CommandGuide/lit.rst b/llvm/docs/CommandGuide/lit.rst index 938b7f9..eb90e95 100644 --- a/llvm/docs/CommandGuide/lit.rst +++ b/llvm/docs/CommandGuide/lit.rst @@ -356,6 +356,11 @@ The timing data is stored in the `test_exec_root` in a file named primary purpose is to suppress an ``XPASS`` result without modifying a test case that uses the ``XFAIL`` directive. +.. option:: --exclude-xfail + + ``XFAIL`` tests won't be run, unless they are listed in the ``--xfail-not`` + (or ``LIT_XFAIL_NOT``) lists. + .. option:: --num-shards M Divide the set of selected tests into ``M`` equal-sized subsets or diff --git a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst index 8f15e03..1e0b581 100644 --- a/llvm/docs/CommandGuide/llvm-bcanalyzer.rst +++ b/llvm/docs/CommandGuide/llvm-bcanalyzer.rst @@ -14,7 +14,7 @@ DESCRIPTION The :program:`llvm-bcanalyzer` command is a small utility for analyzing bitcode files. The tool reads a bitcode file (such as generated with the :program:`llvm-as` tool) and produces a statistical report on the contents of -the bitcode file. The tool can also dump a low level but human readable +the bitcode file. The tool can also dump a low level but human-readable version of the bitcode file. This tool is probably not of much interest or utility except for those working directly with the bitcode file format. Most LLVM users can just ignore this tool. @@ -30,7 +30,7 @@ OPTIONS .. option:: --dump - Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human readable + Causes :program:`llvm-bcanalyzer` to dump the bitcode in a human-readable format. This format is significantly different from LLVM assembly and provides details about the encoding of the bitcode file. diff --git a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst index 1264f80..6a4e348 100644 --- a/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst +++ b/llvm/docs/CommandGuide/llvm-debuginfo-analyzer.rst @@ -14,7 +14,7 @@ DESCRIPTION ----------- :program:`llvm-debuginfo-analyzer` parses debug and text sections in binary object files and prints their contents in a logical view, which -is a human readable representation that closely matches the structure +is a human-readable representation that closely matches the structure of the original user source code. Supported object file formats include ELF, Mach-O, WebAssembly, PDB and COFF. diff --git a/llvm/docs/CommandGuide/llvm-exegesis.rst b/llvm/docs/CommandGuide/llvm-exegesis.rst index 25e8969..5996026 100644 --- a/llvm/docs/CommandGuide/llvm-exegesis.rst +++ b/llvm/docs/CommandGuide/llvm-exegesis.rst @@ -106,7 +106,7 @@ properly. using the loop repetition mode. :program:`llvm-exegesis` needs to keep track of the current loop iteration within the loop repetition mode in a performant manner (i.e., no memory accesses), and uses a register to do this. This register - has an architecture specific default (e.g., `R8` on X86), but this might conflict + has an architecture-specific default (e.g., `R8` on X86), but this might conflict with some snippets. This annotation allows changing the register to prevent interference between the loop index register and the snippet. diff --git a/llvm/docs/CommandGuide/llvm-ifs.rst b/llvm/docs/CommandGuide/llvm-ifs.rst index 1fe81c2..e3582b3 100644 --- a/llvm/docs/CommandGuide/llvm-ifs.rst +++ b/llvm/docs/CommandGuide/llvm-ifs.rst @@ -11,7 +11,7 @@ SYNOPSIS DESCRIPTION ----------- -:program:`llvm-ifs` is a tool that jointly produces human readable text-based +:program:`llvm-ifs` is a tool that jointly produces human-readable text-based stubs (.ifs files) for shared objects and linkable shared object stubs (.so files) from either ELF shared objects or text-based stubs. The text-based stubs is useful for monitoring ABI changes of the shared object. The linkable diff --git a/llvm/docs/CommandGuide/llvm-ir2vec.rst b/llvm/docs/CommandGuide/llvm-ir2vec.rst index d90e0e4..0c9fb6e 100644 --- a/llvm/docs/CommandGuide/llvm-ir2vec.rst +++ b/llvm/docs/CommandGuide/llvm-ir2vec.rst @@ -6,27 +6,27 @@ llvm-ir2vec - IR2Vec Embedding Generation Tool SYNOPSIS -------- -:program:`llvm-ir2vec` [*options*] *input-file* +:program:`llvm-ir2vec` [*subcommand*] [*options*] DESCRIPTION ----------- :program:`llvm-ir2vec` is a standalone command-line tool for IR2Vec. It generates IR2Vec embeddings for LLVM IR and supports triplet generation -for vocabulary training. It provides three main operation modes: +for vocabulary training. The tool provides three main subcommands: -1. **Triplet Mode**: Generates numeric triplets in train2id format for vocabulary +1. **triplets**: Generates numeric triplets in train2id format for vocabulary training from LLVM IR. -2. **Entity Mode**: Generates entity mapping files (entity2id.txt) for vocabulary +2. **entities**: Generates entity mapping files (entity2id.txt) for vocabulary training. -3. **Embedding Mode**: Generates IR2Vec embeddings using a trained vocabulary +3. **embeddings**: Generates IR2Vec embeddings using a trained vocabulary at different granularity levels (instruction, basic block, or function). The tool is designed to facilitate machine learning applications that work with LLVM IR by converting the IR into numerical representations that can be used by -ML models. The triplet mode generates numeric IDs directly instead of string +ML models. The `triplets` subcommand generates numeric IDs directly instead of string triplets, streamlining the training data preparation workflow. .. note:: @@ -50,111 +50,118 @@ embedding training (see <https://github.com/thunlp/OpenKE/tree/OpenKE-PyTorch?tab=readme-ov-file#data-format> for details). -Triplet Generation Mode -~~~~~~~~~~~~~~~~~~~~~~~ +See `llvm/utils/mlgo-utils/IR2Vec/generateTriplets.py` for more details on how +these two modes are used to generate the triplets and entity mappings. -In triplet mode, :program:`llvm-ir2vec` analyzes LLVM IR and extracts numeric -triplets consisting of opcode IDs, type IDs, and operand IDs. These triplets -are generated in the standard format used for knowledge graph embedding training. -The tool outputs numeric IDs directly using the ir2vec::Vocabulary mapping +Triplet Generation +~~~~~~~~~~~~~~~~~~ + +With the `triplets` subcommand, :program:`llvm-ir2vec` analyzes LLVM IR and extracts +numeric triplets consisting of opcode IDs, type IDs, and operand IDs. These triplets +are generated in the standard format used for knowledge graph embedding training. +The tool outputs numeric IDs directly using the ir2vec::Vocabulary mapping infrastructure, eliminating the need for string-to-ID preprocessing. Usage: .. code-block:: bash - llvm-ir2vec --mode=triplets input.bc -o triplets_train2id.txt + llvm-ir2vec triplets input.bc -o triplets_train2id.txt -Entity Mapping Generation Mode -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Entity Mapping Generation +~~~~~~~~~~~~~~~~~~~~~~~~~ -In entity mode, :program:`llvm-ir2vec` generates the entity mappings supported by -IR2Vec in the standard format used for knowledge graph embedding training. This -mode outputs all supported entities (opcodes, types, and operands) with their -corresponding numeric IDs, and is not specific for an LLVM IR file. +With the `entities` subcommand, :program:`llvm-ir2vec` generates the entity mappings +supported by IR2Vec in the standard format used for knowledge graph embedding +training. This subcommand outputs all supported entities (opcodes, types, and +operands) with their corresponding numeric IDs, and is not specific for an +LLVM IR file. Usage: .. code-block:: bash - llvm-ir2vec --mode=entities -o entity2id.txt + llvm-ir2vec entities -o entity2id.txt -Embedding Generation Mode -~~~~~~~~~~~~~~~~~~~~~~~~~~ +Embedding Generation +~~~~~~~~~~~~~~~~~~~~ -In embedding mode, :program:`llvm-ir2vec` uses a pre-trained vocabulary to +With the `embeddings` subcommand, :program:`llvm-ir2vec` uses a pre-trained vocabulary to generate numerical embeddings for LLVM IR at different levels of granularity. Example Usage: .. code-block:: bash - llvm-ir2vec --mode=embeddings --ir2vec-vocab-path=vocab.json --level=func input.bc -o embeddings.txt + llvm-ir2vec embeddings --ir2vec-vocab-path=vocab.json --level=func input.bc -o embeddings.txt OPTIONS ------- -.. option:: --mode=<mode> +Global options: + +.. option:: -o <filename> + + Specify the output filename. Use ``-`` to write to standard output (default). + +.. option:: --help + + Print a summary of command line options. - Specify the operation mode. Valid values are: +Subcommand-specific options: - * ``triplets`` - Generate triplets for vocabulary training - * ``entities`` - Generate entity mappings for vocabulary training - * ``embeddings`` - Generate embeddings using trained vocabulary (default) +**embeddings** subcommand: + +.. option:: <input-file> + + The input LLVM IR or bitcode file to process. This positional argument is + required for the `embeddings` subcommand. .. option:: --level=<level> - Specify the embedding generation level. Valid values are: + Specify the embedding generation level. Valid values are: - * ``inst`` - Generate instruction-level embeddings - * ``bb`` - Generate basic block-level embeddings - * ``func`` - Generate function-level embeddings (default) + * ``inst`` - Generate instruction-level embeddings + * ``bb`` - Generate basic block-level embeddings + * ``func`` - Generate function-level embeddings (default) .. option:: --function=<name> - Process only the specified function instead of all functions in the module. + Process only the specified function instead of all functions in the module. .. option:: --ir2vec-vocab-path=<path> - Specify the path to the vocabulary file (required for embedding mode). - The vocabulary file should be in JSON format and contain the trained - vocabulary for embedding generation. See `llvm/lib/Analysis/models` - for pre-trained vocabulary files. + Specify the path to the vocabulary file (required for embedding generation). + The vocabulary file should be in JSON format and contain the trained + vocabulary for embedding generation. See `llvm/lib/Analysis/models` + for pre-trained vocabulary files. .. option:: --ir2vec-opc-weight=<weight> - Specify the weight for opcode embeddings (default: 1.0). This controls - the relative importance of instruction opcodes in the final embedding. + Specify the weight for opcode embeddings (default: 1.0). This controls + the relative importance of instruction opcodes in the final embedding. .. option:: --ir2vec-type-weight=<weight> - Specify the weight for type embeddings (default: 0.5). This controls - the relative importance of type information in the final embedding. + Specify the weight for type embeddings (default: 0.5). This controls + the relative importance of type information in the final embedding. .. option:: --ir2vec-arg-weight=<weight> - Specify the weight for argument embeddings (default: 0.2). This controls - the relative importance of operand information in the final embedding. + Specify the weight for argument embeddings (default: 0.2). This controls + the relative importance of operand information in the final embedding. -.. option:: -o <filename> - Specify the output filename. Use ``-`` to write to standard output (default). +**triplets** subcommand: -.. option:: --help - - Print a summary of command line options. - -.. note:: +.. option:: <input-file> - ``--level``, ``--function``, ``--ir2vec-vocab-path``, ``--ir2vec-opc-weight``, - ``--ir2vec-type-weight``, and ``--ir2vec-arg-weight`` are only used in embedding - mode. These options are ignored in triplet and entity modes. + The input LLVM IR or bitcode file to process. This positional argument is + required for the `triplets` subcommand. -INPUT FILE FORMAT ------------------ +**entities** subcommand: -:program:`llvm-ir2vec` accepts LLVM bitcode files (``.bc``) and LLVM IR files -(``.ll``) as input. The input file should contain valid LLVM IR. + No subcommand-specific options. OUTPUT FORMAT ------------- diff --git a/llvm/docs/CommandGuide/llvm-locstats.rst b/llvm/docs/CommandGuide/llvm-locstats.rst index 3186566..7f436c1 100644 --- a/llvm/docs/CommandGuide/llvm-locstats.rst +++ b/llvm/docs/CommandGuide/llvm-locstats.rst @@ -13,7 +13,7 @@ DESCRIPTION :program:`llvm-locstats` works like a wrapper around :program:`llvm-dwarfdump`. It parses :program:`llvm-dwarfdump` statistics regarding debug location by -pretty printing it in a more human readable way. +pretty printing it in a more human-readable way. The line 0% shows the number and the percentage of DIEs with no location information, but the line 100% shows the information for DIEs where there is diff --git a/llvm/docs/CommandGuide/llvm-mca.rst b/llvm/docs/CommandGuide/llvm-mca.rst index bea1931..1daae5d 100644 --- a/llvm/docs/CommandGuide/llvm-mca.rst +++ b/llvm/docs/CommandGuide/llvm-mca.rst @@ -241,7 +241,7 @@ option specifies "``-``", then the output will also be sent to standard output. .. option:: -disable-cb Force usage of the generic CustomBehaviour and InstrPostProcess classes rather - than using the target specific implementation. The generic classes never + than using the target-specific implementation. The generic classes never detect any custom hazards or make any post processing modifications to instructions. @@ -1125,9 +1125,9 @@ CustomBehaviour class can be used in these cases to enforce proper instruction modeling (often by customizing data dependencies and detecting hazards that :program:`llvm-mca` has no way of knowing about). -:program:`llvm-mca` comes with one generic and multiple target specific +:program:`llvm-mca` comes with one generic and multiple target-specific CustomBehaviour classes. The generic class will be used if the ``-disable-cb`` -flag is used or if a target specific CustomBehaviour class doesn't exist for +flag is used or if a target-specific CustomBehaviour class doesn't exist for that target. (The generic class does nothing.) Currently, the CustomBehaviour class is only a part of the in-order pipeline, but there are plans to add it to the out-of-order pipeline in the future. @@ -1141,7 +1141,7 @@ if you don't know the exact number and a value of 0 represents no stall). If you'd like to add a CustomBehaviour class for a target that doesn't already have one, refer to an existing implementation to see how to set it -up. The classes are implemented within the target specific backend (for +up. The classes are implemented within the target-specific backend (for example `/llvm/lib/Target/AMDGPU/MCA/`) so that they can access backend symbols. Instrument Manager @@ -1177,12 +1177,12 @@ classes (MCSubtargetInfo, MCInstrInfo, etc.), please add it to the AND requires unexposed backend symbols or functionality, you can define it in the `/lib/Target/<TargetName>/MCA/` directory. -To enable this target specific View, you will have to use this target's +To enable this target-specific View, you will have to use this target's CustomBehaviour class to override the `CustomBehaviour::getViews()` methods. There are 3 variations of these methods based on where you want your View to appear in the output: `getStartViews()`, `getPostInstrInfoViews()`, and `getEndViews()`. These methods returns a vector of Views so you will want to -return a vector containing all of the target specific Views for the target in +return a vector containing all of the target-specific Views for the target in question. Because these target specific (and backend dependent) Views require the diff --git a/llvm/docs/CommandGuide/llvm-profdata.rst b/llvm/docs/CommandGuide/llvm-profdata.rst index b2c0457..0b1cd02 100644 --- a/llvm/docs/CommandGuide/llvm-profdata.rst +++ b/llvm/docs/CommandGuide/llvm-profdata.rst @@ -338,7 +338,7 @@ OPTIONS Instruct the profile dumper to show profile counts in the text format of the instrumentation-based profile data representation. By default, the profile - information is dumped in a more human readable form (also in text) with + information is dumped in a more human-readable form (also in text) with annotations. .. option:: --topn=<n> diff --git a/llvm/docs/CommandGuide/llvm-symbolizer.rst b/llvm/docs/CommandGuide/llvm-symbolizer.rst index 2da1b24..fb86a69 100644 --- a/llvm/docs/CommandGuide/llvm-symbolizer.rst +++ b/llvm/docs/CommandGuide/llvm-symbolizer.rst @@ -371,7 +371,7 @@ OPTIONS * Prints an address's debug-data discriminator when it is non-zero. One way to produce discriminators is to compile with clang's -fdebug-info-for-profiling. - ``JSON`` style provides a machine readable output in JSON. If addresses are + ``JSON`` style provides a machine-readable output in JSON. If addresses are supplied via stdin, the output JSON will be a series of individual objects. Otherwise, all results will be contained in a single array. @@ -444,7 +444,7 @@ OPTIONS .. option:: --pretty-print, -p - Print human readable output. If :option:`--inlining` is specified, the + Print human-readable output. If :option:`--inlining` is specified, the enclosing scope is prefixed by (inlined by). For JSON output, the option will cause JSON to be indented and split over new lines. Otherwise, the JSON output will be printed in a compact form. diff --git a/llvm/docs/CommandGuide/opt.rst b/llvm/docs/CommandGuide/opt.rst index f067f62..da93b8e 100644 --- a/llvm/docs/CommandGuide/opt.rst +++ b/llvm/docs/CommandGuide/opt.rst @@ -46,12 +46,12 @@ OPTIONS Write output in LLVM intermediate language (instead of bitcode). -.. option:: -{passname} +.. option:: -passes=<string> - :program:`opt` provides the ability to run any of LLVM's optimization or - analysis passes in any order. The :option:`-help` option lists all the passes - available. The order in which the options occur on the command line are the - order in which they are executed (within pass constraints). + A textual (comma-separated) description of the pass pipeline, + e.g., ``-passes="sroa,instcombine"``. See + `invoking opt <../NewPassManager.html#invoking-opt>`_ for more details on the + pass pipeline syntax. .. option:: -strip-debug diff --git a/llvm/docs/DirectX/DXContainer.rst b/llvm/docs/DirectX/DXContainer.rst index 4ace8a1..17452d9 100644 --- a/llvm/docs/DirectX/DXContainer.rst +++ b/llvm/docs/DirectX/DXContainer.rst @@ -280,7 +280,7 @@ elements are: This represents ``f5`` in the source. The LLVM ``obj2yaml`` tool can parse this data out of the PSV and present it in -human readable YAML. For the example above it produces the output: +human-readable YAML. For the example above it produces the output: .. code-block:: YAML diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst index 4baf127..b81df70 100644 --- a/llvm/docs/Frontend/PerformanceTips.rst +++ b/llvm/docs/Frontend/PerformanceTips.rst @@ -35,7 +35,7 @@ The Basics ^^^^^^^^^^^ #. Make sure that your Modules contain both a data layout specification and - target triple. Without these pieces, non of the target specific optimization + target triple. Without these pieces, non of the target-specific optimization will be enabled. This can have a major effect on the generated code quality. #. For each function or global emitted, use the most private linkage type diff --git a/llvm/docs/FuzzingLLVM.rst b/llvm/docs/FuzzingLLVM.rst index 6b32eea..a0355d7 100644 --- a/llvm/docs/FuzzingLLVM.rst +++ b/llvm/docs/FuzzingLLVM.rst @@ -128,7 +128,7 @@ llvm-mc-assemble-fuzzer ----------------------- A |generic fuzzer| that fuzzes the MC layer's assemblers by treating inputs as -target specific assembly. +target-specific assembly. Note that this fuzzer has an unusual command line interface which is not fully compatible with all of libFuzzer's features. Fuzzer arguments must be passed diff --git a/llvm/docs/GettingStarted.rst b/llvm/docs/GettingStarted.rst index e4dbb64b..8d0adf3 100644 --- a/llvm/docs/GettingStarted.rst +++ b/llvm/docs/GettingStarted.rst @@ -919,11 +919,11 @@ the `Command Guide <CommandGuide/index.html>`_. ``llvm-as`` - The assembler transforms the human readable LLVM assembly to LLVM bitcode. + The assembler transforms the human-readable LLVM assembly to LLVM bitcode. ``llvm-dis`` - The disassembler transforms the LLVM bitcode to human readable LLVM assembly. + The disassembler transforms the LLVM bitcode to human-readable LLVM assembly. ``llvm-link`` diff --git a/llvm/docs/GlobalISel/GMIR.rst b/llvm/docs/GlobalISel/GMIR.rst index 633dfb8..be7e677 100644 --- a/llvm/docs/GlobalISel/GMIR.rst +++ b/llvm/docs/GlobalISel/GMIR.rst @@ -26,7 +26,7 @@ Generic Machine Instructions Reference. Whereas MIR deals largely in Target Instructions and only has a small set of -target independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``, +target-independent opcodes such as ``COPY``, ``PHI``, and ``REG_SEQUENCE``, gMIR defines a rich collection of ``Generic Opcodes`` which are target independent and describe operations which are typically supported by targets. One example is ``G_ADD`` which is the generic opcode for an integer addition. diff --git a/llvm/docs/GlobalISel/GenericOpcode.rst b/llvm/docs/GlobalISel/GenericOpcode.rst index 4816094..eefd76d 100644 --- a/llvm/docs/GlobalISel/GenericOpcode.rst +++ b/llvm/docs/GlobalISel/GenericOpcode.rst @@ -1105,7 +1105,7 @@ G_TRAP, G_DEBUGTRAP, G_UBSANTRAP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Represents :ref:`llvm.trap <llvm.trap>`, :ref:`llvm.debugtrap <llvm.debugtrap>` -and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target dependent +and :ref:`llvm.ubsantrap <llvm.ubsantrap>` that generate a target-dependent trap instructions. .. code-block:: none diff --git a/llvm/docs/GlobalISel/Pipeline.rst b/llvm/docs/GlobalISel/Pipeline.rst index 01bd4df..b9085e8 100644 --- a/llvm/docs/GlobalISel/Pipeline.rst +++ b/llvm/docs/GlobalISel/Pipeline.rst @@ -80,7 +80,7 @@ Combiner alternatives but Combiners can also focus on code size or other metrics. Additional passes such as these can be inserted to support higher optimization -levels or target specific needs. A likely pipeline is: +levels or target-specific needs. A likely pipeline is: .. image:: pipeline-overview-with-combiners.png diff --git a/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst b/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst index 2e199a0..31ead45 100644 --- a/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst +++ b/llvm/docs/HowToCrossCompileBuiltinsOnArm.rst @@ -14,117 +14,113 @@ targets are welcome. The instructions in this document depend on libraries and programs external to LLVM, there are many ways to install and configure these dependencies so you -may need to adapt the instructions here to fit your own local situation. +may need to adapt the instructions here to fit your own situation. Prerequisites ============= -In this use case we'll be using cmake on a Debian-based Linux system, -cross-compiling from an x86_64 host to a hard-float Armv7-A target. We'll be +In this use case we will be using cmake on a Debian-based Linux system, +cross-compiling from an x86_64 host to a hard-float Armv7-A target. We will be using as many of the LLVM tools as we can, but it is possible to use GNU equivalents. - * ``A build of LLVM/clang for the llvm-tools and llvm-config`` - * ``A clang executable with support for the ARM target`` - * ``compiler-rt sources`` - * ``The qemu-arm user mode emulator`` - * ``An arm-linux-gnueabihf sysroot`` +You will need: + * A build of LLVM for the llvm-tools and ``llvm-config``. + * A clang executable with support for the ``ARM`` target. + * compiler-rt sources. + * The ``qemu-arm`` user mode emulator. + * An ``arm-linux-gnueabihf`` sysroot. -In this example we will be using ninja. +In this example we will be using ``ninja`` as the build tool. -See https://compiler-rt.llvm.org/ for more information about the dependencies +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 -the source for LLVM and compiler-rt. Note that the getting started guide -places compiler-rt in the projects subdirectory, but this is not essential and -if you are using the BaremetalARM.cmake cache for v6-M, v7-M and v7-EM then -compiler-rt must be placed in the runtimes directory. +the source for LLVM and compiler-rt. ``qemu-arm`` should be available as a package for your Linux distribution. -The most complicated of the prerequisites to satisfy is the arm-linux-gnueabihf +The most complicated of the prerequisites to satisfy is the ``arm-linux-gnueabihf`` sysroot. In theory it is possible to use the Linux distributions multiarch support to fulfill the dependencies for building but unfortunately due to -/usr/local/include being added some host includes are selected. The easiest way -to supply a sysroot is to download the arm-linux-gnueabihf toolchain. This can -be found at: -* https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads for gcc 8 and above -* https://releases.linaro.org/components/toolchain/binaries/ for gcc 4.9 to 7.3 +``/usr/local/include`` being added some host includes are selected. + +The easiest way to supply a sysroot is to download an ``arm-linux-gnueabihf`` +toolchain from https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads. Building compiler-rt builtins for Arm ===================================== + We will be doing a standalone build of compiler-rt using the following cmake -options. - -* ``path/to/compiler-rt`` -* ``-G Ninja`` -* ``-DCMAKE_AR=/path/to/llvm-ar`` -* ``-DCMAKE_ASM_COMPILER_TARGET="arm-linux-gnueabihf"`` -* ``-DCMAKE_ASM_FLAGS="build-c-flags"`` -* ``-DCMAKE_C_COMPILER=/path/to/clang`` -* ``-DCMAKE_C_COMPILER_TARGET="arm-linux-gnueabihf"`` -* ``-DCMAKE_C_FLAGS="build-c-flags"`` -* ``-DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld"`` -* ``-DCMAKE_NM=/path/to/llvm-nm`` -* ``-DCMAKE_RANLIB=/path/to/llvm-ranlib`` -* ``-DCOMPILER_RT_BUILD_BUILTINS=ON`` -* ``-DCOMPILER_RT_BUILD_LIBFUZZER=OFF`` -* ``-DCOMPILER_RT_BUILD_MEMPROF=OFF`` -* ``-DCOMPILER_RT_BUILD_PROFILE=OFF`` -* ``-DCOMPILER_RT_BUILD_SANITIZERS=OFF`` -* ``-DCOMPILER_RT_BUILD_XRAY=OFF`` -* ``-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON`` -* ``-DLLVM_CONFIG_PATH=/path/to/llvm-config`` +options:: + + cmake path/to/compiler-rt \ + -G Ninja \ + -DCMAKE_AR=/path/to/llvm-ar \ + -DCMAKE_ASM_COMPILER_TARGET="arm-linux-gnueabihf" \ + -DCMAKE_ASM_FLAGS="build-c-flags" \ + -DCMAKE_C_COMPILER=/path/to/clang \ + -DCMAKE_C_COMPILER_TARGET="arm-linux-gnueabihf" \ + -DCMAKE_C_FLAGS="build-c-flags" \ + -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" \ + -DCMAKE_NM=/path/to/llvm-nm \ + -DCMAKE_RANLIB=/path/to/llvm-ranlib \ + -DCOMPILER_RT_BUILD_BUILTINS=ON \ + -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \ + -DCOMPILER_RT_BUILD_MEMPROF=OFF \ + -DCOMPILER_RT_BUILD_PROFILE=OFF \ + -DCOMPILER_RT_BUILD_SANITIZERS=OFF \ + -DCOMPILER_RT_BUILD_XRAY=OFF \ + -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \ + -DLLVM_CONFIG_PATH=/path/to/llvm-config The ``build-c-flags`` need to be sufficient to pass the C-make compiler check, compile compiler-rt, and if you are running the tests, compile and link the tests. When cross-compiling with clang we will need to pass sufficient -information to generate code for the Arm architecture we are targeting. We will -need to select the Arm target, select the Armv7-A architecture and choose -between using Arm or Thumb. -instructions. For example: +information to generate code for the Arm architecture we are targeting. -* ``--target=arm-linux-gnueabihf`` -* ``-march=armv7a`` -* ``-mthumb`` +We will need to select: + * The Arm target and Armv7-A architecture with ``--target=arm-linux-gnueabihf -march=armv7a``. + * Whether to generate Arm (the default) or Thumb instructions (``-mthumb``). -When using a GCC arm-linux-gnueabihf toolchain the following flags are +When using a GCC ``arm-linux-gnueabihf`` toolchain the following flags are needed to pick up the includes and libraries: -* ``--gcc-toolchain=/path/to/dir/toolchain`` -* ``--sysroot=/path/to/toolchain/arm-linux-gnueabihf/libc`` + * ``--gcc-toolchain=/path/to/dir/toolchain`` + * ``--sysroot=/path/to/toolchain/arm-linux-gnueabihf/libc`` In this example we will be adding all of the command line options to both ``CMAKE_C_FLAGS`` and ``CMAKE_ASM_FLAGS``. There are cmake flags to pass some of -these options individually which can be used to simplify the ``build-c-flags``: +these options individually which can be used to simplify the ``build-c-flags``:: -* ``-DCMAKE_C_COMPILER_TARGET="arm-linux-gnueabihf"`` -* ``-DCMAKE_ASM_COMPILER_TARGET="arm-linux-gnueabihf"`` -* ``-DCMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN=/path/to/dir/toolchain`` -* ``-DCMAKE_SYSROOT=/path/to/dir/toolchain/arm-linux-gnueabihf/libc`` + -DCMAKE_C_COMPILER_TARGET="arm-linux-gnueabihf" + -DCMAKE_ASM_COMPILER_TARGET="arm-linux-gnueabihf" + -DCMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN=/path/to/dir/toolchain + -DCMAKE_SYSROOT=/path/to/dir/toolchain/arm-linux-gnueabihf/libc Once cmake has completed the builtins can be built with ``ninja builtins`` Testing compiler-rt builtins using qemu-arm =========================================== + To test the builtins library we need to add a few more cmake flags to enable testing and set up the compiler and flags for test case. We must also tell -cmake that we wish to run the tests on ``qemu-arm``. +cmake that we wish to run the tests on ``qemu-arm``:: -* ``-DCOMPILER_RT_EMULATOR="qemu-arm -L /path/to/armhf/sysroot`` -* ``-DCOMPILER_RT_INCLUDE_TESTS=ON`` -* ``-DCOMPILER_RT_TEST_COMPILER="/path/to/clang"`` -* ``-DCOMPILER_RT_TEST_COMPILER_CFLAGS="test-c-flags"`` + -DCOMPILER_RT_EMULATOR="qemu-arm -L /path/to/armhf/sysroot" + -DCOMPILER_RT_INCLUDE_TESTS=ON + -DCOMPILER_RT_TEST_COMPILER="/path/to/clang" + -DCOMPILER_RT_TEST_COMPILER_CFLAGS="test-c-flags" The ``/path/to/armhf/sysroot`` should be the same as the one passed to -``--sysroot`` in the "build-c-flags". +``--sysroot`` in the ``build-c-flags``. -The "test-c-flags" need to include the target, architecture, gcc-toolchain, -sysroot and arm/thumb state. The additional cmake defines such as +The ``test-c-flags`` need to include the target, architecture, gcc-toolchain, +sysroot and Arm/Thumb state. The additional cmake defines such as ``CMAKE_C_COMPILER_EXTERNAL_TOOLCHAIN`` do not apply when building the tests. If -you have put all of these in "build-c-flags" then these can be repeated. If you -wish to use lld to link the tests then add ``"-fuse-ld=lld``. +you have put all of these in ``build-c-flags`` then these can be repeated. If you +wish to use lld to link the tests then add ``-fuse-ld=lld``. Once cmake has completed the tests can be built and run using ``ninja check-builtins`` @@ -142,19 +138,21 @@ This stage can often fail at link time if the ``--sysroot=`` and ``CMAKE_C_FLAGS`` and ``CMAKE_C_COMPILER_TARGET`` flags. It can be useful to build a simple example outside of cmake with your toolchain -to make sure it is working. For example: ``clang --target=arm-linux-gnueabi -march=armv7a --gcc-toolchain=/path/to/gcc-toolchain --sysroot=/path/to/gcc-toolchain/arm-linux-gnueabihf/libc helloworld.c`` +to make sure it is working. For example:: + + clang --target=arm-linux-gnueabi -march=armv7a --gcc-toolchain=/path/to/gcc-toolchain --sysroot=/path/to/gcc-toolchain/arm-linux-gnueabihf/libc helloworld.c Clang uses the host header files -------------------------------- On debian based systems it is possible to install multiarch support for -arm-linux-gnueabi and arm-linux-gnueabihf. In many cases clang can successfully +``arm-linux-gnueabi`` and ``arm-linux-gnueabihf``. In many cases clang can successfully use this multiarch support when ``--gcc-toolchain=`` and ``--sysroot=`` are not supplied. Unfortunately clang adds ``/usr/local/include`` before ``/usr/include/arm-linux-gnueabihf`` leading to errors when compiling the hosts header files. The multiarch support is not sufficient to build the builtins you will need to -use a separate arm-linux-gnueabihf toolchain. +use a separate ``arm-linux-gnueabihf`` toolchain. No target passed to clang ------------------------- @@ -164,12 +162,13 @@ as ``error: unknown directive .syntax unified``. You can check the clang invocation in the error message to see if there is no ``--target`` or if it is set incorrectly. The cause is usually -``CMAKE_ASM_FLAGS`` not containing ``--target`` or ``CMAKE_ASM_COMPILER_TARGET`` not being present. +``CMAKE_ASM_FLAGS`` not containing ``--target`` or ``CMAKE_ASM_COMPILER_TARGET`` +not being present. Arm architecture not given -------------------------- -The ``--target=arm-linux-gnueabihf`` will default to arm architecture v4t which -cannot assemble the barrier instructions used in the synch_and_fetch source +The ``--target=arm-linux-gnueabihf`` will default to Arm architecture v4t which +cannot assemble the barrier instructions used in the ``synch_and_fetch`` source files. The cause is usually a missing ``-march=armv7a`` from the ``CMAKE_ASM_FLAGS``. @@ -202,7 +201,7 @@ may need extra c-flags such as ``-mfloat-abi=softfp`` for use of floating-point instructions, and ``-mfloat-abi=soft -mfpu=none`` for software floating-point emulation. -You will need to use an arm-linux-gnueabi GNU toolchain for soft-float. +You will need to use an ``arm-linux-gnueabi`` GNU toolchain for soft-float. AArch64 Target -------------- @@ -220,8 +219,12 @@ Armv6-m, Armv7-m and Armv7E-M targets To build and test the libraries using a similar method to Armv7-A is possible but more difficult. The main problems are: -* There isn't a ``qemu-arm`` user-mode emulator for bare-metal systems. The ``qemu-system-arm`` can be used but this is significantly more difficult to setup. -* The targets to compile compiler-rt have the suffix -none-eabi. This uses the BareMetal driver in clang and by default won't find the libraries needed to pass the cmake compiler check. +* There is not a ``qemu-arm`` user-mode emulator for bare-metal systems. + ``qemu-system-arm`` can be used but this is significantly more difficult + to setup. +* The targets to compile compiler-rt have the suffix ``-none-eabi``. This uses + the BareMetal driver in clang and by default will not find the libraries + needed to pass the cmake compiler check. As the Armv6-M, Armv7-M and Armv7E-M builds of compiler-rt only use instructions that are supported on Armv7-A we can still get most of the value of running the @@ -233,32 +236,30 @@ builtins use instructions that are supported on Armv7-A but not Armv6-M, Armv7-M and Armv7E-M. To get the cmake compile test to pass you will need to pass the libraries -needed to successfully link the cmake test via ``CMAKE_CFLAGS``. It is -strongly recommended that you use version 3.6 or above of cmake so you can use -``CMAKE_TRY_COMPILE_TARGET=STATIC_LIBRARY`` to skip the link step. - -* ``-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY`` -* ``-DCOMPILER_RT_OS_DIR="baremetal"`` -* ``-DCOMPILER_RT_BUILD_BUILTINS=ON`` -* ``-DCOMPILER_RT_BUILD_SANITIZERS=OFF`` -* ``-DCOMPILER_RT_BUILD_XRAY=OFF`` -* ``-DCOMPILER_RT_BUILD_LIBFUZZER=OFF`` -* ``-DCOMPILER_RT_BUILD_PROFILE=OFF`` -* ``-DCMAKE_C_COMPILER=${host_install_dir}/bin/clang`` -* ``-DCMAKE_C_COMPILER_TARGET="your *-none-eabi target"`` -* ``-DCMAKE_ASM_COMPILER_TARGET="your *-none-eabi target"`` -* ``-DCMAKE_AR=/path/to/llvm-ar`` -* ``-DCMAKE_NM=/path/to/llvm-nm`` -* ``-DCMAKE_RANLIB=/path/to/llvm-ranlib`` -* ``-DCOMPILER_RT_BAREMETAL_BUILD=ON`` -* ``-DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON`` -* ``-DLLVM_CONFIG_PATH=/path/to/llvm-config`` -* ``-DCMAKE_C_FLAGS="build-c-flags"`` -* ``-DCMAKE_ASM_FLAGS="build-c-flags"`` -* ``-DCOMPILER_RT_EMULATOR="qemu-arm -L /path/to/armv7-A/sysroot"`` -* ``-DCOMPILER_RT_INCLUDE_TESTS=ON`` -* ``-DCOMPILER_RT_TEST_COMPILER="/path/to/clang"`` -* ``-DCOMPILER_RT_TEST_COMPILER_CFLAGS="test-c-flags"`` +needed to successfully link the cmake test via ``CMAKE_CFLAGS``:: + + -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \ + -DCOMPILER_RT_OS_DIR="baremetal" \ + -DCOMPILER_RT_BUILD_BUILTINS=ON \ + -DCOMPILER_RT_BUILD_SANITIZERS=OFF \ + -DCOMPILER_RT_BUILD_XRAY=OFF \ + -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \ + -DCOMPILER_RT_BUILD_PROFILE=OFF \ + -DCMAKE_C_COMPILER=${host_install_dir}/bin/clang \ + -DCMAKE_C_COMPILER_TARGET="your *-none-eabi target" \ + -DCMAKE_ASM_COMPILER_TARGET="your *-none-eabi target" \ + -DCMAKE_AR=/path/to/llvm-ar \ + -DCMAKE_NM=/path/to/llvm-nm \ + -DCMAKE_RANLIB=/path/to/llvm-ranlib \ + -DCOMPILER_RT_BAREMETAL_BUILD=ON \ + -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \ + -DLLVM_CONFIG_PATH=/path/to/llvm-config \ + -DCMAKE_C_FLAGS="build-c-flags" \ + -DCMAKE_ASM_FLAGS="build-c-flags" \ + -DCOMPILER_RT_EMULATOR="qemu-arm -L /path/to/armv7-A/sysroot" \ + -DCOMPILER_RT_INCLUDE_TESTS=ON \ + -DCOMPILER_RT_TEST_COMPILER="/path/to/clang" \ + -DCOMPILER_RT_TEST_COMPILER_CFLAGS="test-c-flags" The Armv6-M builtins will use the soft-float ABI. When compiling the tests for Armv7-A we must include ``"-mthumb -mfloat-abi=soft -mfpu=none"`` in the @@ -267,25 +268,21 @@ test-c-flags. We must use an Armv7-A soft-float abi sysroot for ``qemu-arm``. Depending on the linker used for the test cases you may encounter BuildAttribute mismatches between the M-profile objects from compiler-rt and the A-profile objects from the test. The lld linker does not check the profile -BuildAttribute so it can be used to link the tests by adding -fuse-ld=lld to the +BuildAttribute so it can be used to link the tests by adding ``-fuse-ld=lld`` to the ``COMPILER_RT_TEST_COMPILER_CFLAGS``. Alternative using a cmake cache ------------------------------- If you wish to build, but not test compiler-rt for Armv6-M, Armv7-M or Armv7E-M -the easiest way is to use the BaremetalARM.cmake recipe in clang/cmake/caches. - -You will need a bare metal sysroot such as that provided by the GNU ARM -Embedded toolchain. - -The libraries can be built with the cmake options: +the easiest way is to use the ``BaremetalARM.cmake`` recipe in ``clang/cmake/caches``. -* ``-DBAREMETAL_ARMV6M_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi`` -* ``-DBAREMETAL_ARMV7M_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi`` -* ``-DBAREMETAL_ARMV7EM_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi`` -* ``-C /path/to/llvm/source/tools/clang/cmake/caches/BaremetalARM.cmake`` -* ``/path/to/llvm`` +You will need a bare metal sysroot such as that provided by the GNU ARM Embedded +toolchain. -**Note** that for the recipe to work the compiler-rt source must be checked out -into the directory llvm/runtimes. You will also need clang and lld checked out. +The libraries can be built with the cmake options:: + -DBAREMETAL_ARMV6M_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi \ + -DBAREMETAL_ARMV7M_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi \ + -DBAREMETAL_ARMV7EM_SYSROOT=/path/to/bare/metal/toolchain/arm-none-eabi \ + -C /path/to/llvm/source/tools/clang/cmake/caches/BaremetalARM.cmake \ + /path/to/llvm diff --git a/llvm/docs/HowToUpdateDebugInfo.rst b/llvm/docs/HowToUpdateDebugInfo.rst index 915e289..ca420e7 100644 --- a/llvm/docs/HowToUpdateDebugInfo.rst +++ b/llvm/docs/HowToUpdateDebugInfo.rst @@ -499,7 +499,7 @@ a JSON file as follows: $ opt -verify-debuginfo-preserve -verify-di-preserve-export=sample.json -pass-to-test sample.ll and then use the ``llvm/utils/llvm-original-di-preservation.py`` script -to generate an HTML page with the issues reported in a more human readable form +to generate an HTML page with the issues reported in a more human-readable form as follows: .. code-block:: bash diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst index 8902712..370281b 100644 --- a/llvm/docs/JITLink.rst +++ b/llvm/docs/JITLink.rst @@ -1072,7 +1072,7 @@ Major outstanding projects include: * Refactor architecture support to maximize sharing across formats. - All formats should be able to share the bulk of the architecture specific + All formats should be able to share the bulk of the architecture-specific code (especially relocations) for each supported architecture. * Refactor ELF link graph construction. diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst index 28746bf..2a8f0af 100644 --- a/llvm/docs/LangRef.rst +++ b/llvm/docs/LangRef.rst @@ -26,7 +26,7 @@ readable assembly language representation. This allows LLVM to provide a powerful intermediate representation for efficient compiler transformations and analysis, while providing a natural means to debug and visualize the transformations. The three different forms of LLVM are -all equivalent. This document describes the human readable +all equivalent. This document describes the human-readable representation and notation. The LLVM representation aims to be light-weight and low-level while @@ -21289,7 +21289,7 @@ Semantics: On some architectures the address of the code to be executed needs to be different than the address where the trampoline is actually stored. This intrinsic returns the executable address corresponding to ``tramp`` -after performing the required machine specific adjustments. The pointer +after performing the required machine-specific adjustments. The pointer returned can then be :ref:`bitcast and executed <int_trampoline>`. @@ -29382,7 +29382,7 @@ None. Semantics: """""""""" -This intrinsic is lowered to the target dependent trap instruction. If +This intrinsic is lowered to the target-dependent trap instruction. If the target does not have a trap instruction, this intrinsic will be lowered to a call of the ``abort()`` function. diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst index 1d4894f..05315a8 100644 --- a/llvm/docs/Lexicon.rst +++ b/llvm/docs/Lexicon.rst @@ -192,7 +192,7 @@ L **LSDA** Language Specific Data Area. C++ "zero cost" unwinding is built on top a generic unwinding mechanism. As the unwinder walks each frame, it calls - a "personality" function to do language specific analysis. Each function's + a "personality" function to do language-specific analysis. Each function's FDE points to an optional LSDA which is passed to the personality function. For C++, the LSDA contain info about the type and location of catch statements in that function. diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst index b4b59db..a505c1e 100644 --- a/llvm/docs/MIRLangRef.rst +++ b/llvm/docs/MIRLangRef.rst @@ -12,7 +12,7 @@ Introduction ============ This document is a reference manual for the Machine IR (MIR) serialization -format. MIR is a human readable serialization format that is used to represent +format. MIR is a human-readable serialization format that is used to represent LLVM's :ref:`machine specific intermediate representation <machine code representation>`. @@ -221,7 +221,7 @@ Machine Instructions Format Reference ===================================== The machine basic blocks and their instructions are represented using a custom, -human readable serialization language. This language is used in the +human-readable serialization language. This language is used in the `YAML block literal string`_ that corresponds to the machine function's body. A source string that uses this language contains a list of machine basic diff --git a/llvm/docs/PDB/CodeViewTypes.rst b/llvm/docs/PDB/CodeViewTypes.rst index 7a93ebe..996d8f9 100644 --- a/llvm/docs/PDB/CodeViewTypes.rst +++ b/llvm/docs/PDB/CodeViewTypes.rst @@ -123,7 +123,7 @@ The ``Size`` field of the Attributes bitmask is a 1-byte value indicating the pointer size. For example, a `void*` would have a size of either 4 or 8 depending on the target architecture. On the other hand, if ``Mode`` indicates that this is a pointer to member function or pointer to data member, then the size can be any -implementation defined number. +implementation-defined number. The ``Member Ptr Info`` field of the ``LF_POINTER`` record is only present if the attributes indicate that this is a pointer to member. diff --git a/llvm/docs/ReleaseNotes.md b/llvm/docs/ReleaseNotes.md index 021f321..0c49fc8 100644 --- a/llvm/docs/ReleaseNotes.md +++ b/llvm/docs/ReleaseNotes.md @@ -137,6 +137,9 @@ Changes to the LLVM tools Changes to LLDB --------------------------------- +* LLDB can now set breakpoints, show backtraces, and display variables when + debugging Wasm with supported runtimes (WAMR and V8). + Changes to BOLT --------------------------------- diff --git a/llvm/docs/SPIRVUsage.rst b/llvm/docs/SPIRVUsage.rst index 1f563fb..fdefc53 100644 --- a/llvm/docs/SPIRVUsage.rst +++ b/llvm/docs/SPIRVUsage.rst @@ -131,9 +131,23 @@ Extensions The SPIR-V backend supports a variety of `extensions <https://github.com/KhronosGroup/SPIRV-Registry/tree/main/extensions>`_ that enable or enhance features beyond the core SPIR-V specification. -These extensions can be enabled using the ``-spirv-extensions`` option -followed by the name of the extension(s) you wish to enable. Below is a -list of supported SPIR-V extensions, sorted alphabetically by their extension names: +The enabled extensions can be controlled using the ``-spirv-ext`` option followed by a list of +extensions to enable or disable, each prefixed with ``+`` or ``-``, respectively. + +To enable multiple extensions, list them separated by comma. For example, to enable support for atomic operations on floating-point numbers and arbitrary precision integers, use: + +``-spirv-ext=+SPV_EXT_shader_atomic_float_add,+SPV_INTEL_arbitrary_precision_integers`` + +To enable all extensions, use the following option: +``-spirv-ext=all`` + +To enable all KHR extensions, use the following option: +``-spirv-ext=khr`` + +To enable all extensions except specified, specify ``all`` followed by a list of disallowed extensions. For example: +``-spirv-ext=all,-SPV_INTEL_arbitrary_precision_integers`` + +Below is a list of supported SPIR-V extensions, sorted alphabetically by their extension names: .. list-table:: Supported SPIR-V Extensions :widths: 50 150 @@ -220,16 +234,6 @@ list of supported SPIR-V extensions, sorted alphabetically by their extension na * - ``SPV_KHR_float_controls2`` - Adds ability to specify the floating-point environment in shaders. It can be used on whole modules and individual instructions. -To enable multiple extensions, list them separated by comma. For example, to enable support for atomic operations on floating-point numbers and arbitrary precision integers, use: - -``-spirv-ext=+SPV_EXT_shader_atomic_float_add,+SPV_INTEL_arbitrary_precision_integers`` - -To enable all extensions, use the following option: -``-spirv-ext=all`` - -To enable all extensions except specified, specify ``all`` followed by a list of disallowed extensions. For example: -``-spirv-ext=all,-SPV_INTEL_arbitrary_precision_integers`` - SPIR-V representation in LLVM IR ================================ diff --git a/llvm/docs/SymbolizerMarkupFormat.rst b/llvm/docs/SymbolizerMarkupFormat.rst index d5b17d7..75ead44 100644 --- a/llvm/docs/SymbolizerMarkupFormat.rst +++ b/llvm/docs/SymbolizerMarkupFormat.rst @@ -315,7 +315,7 @@ Trigger elements ================ These elements cause an external action and will be presented to the user in a -human readable form. Generally they trigger an external action to occur that +human-readable form. Generally they trigger an external action to occur that results in a linkable page. The link or some other informative information about the external action can then be presented to the user. diff --git a/llvm/docs/TableGen/BackGuide.rst b/llvm/docs/TableGen/BackGuide.rst index 4828f9b..83f8f470 100644 --- a/llvm/docs/TableGen/BackGuide.rst +++ b/llvm/docs/TableGen/BackGuide.rst @@ -191,7 +191,7 @@ Some of these classes have additional members that are described in the following subsections. *All* of the classes derived from ``RecTy`` provide the ``get()`` function. -It returns an instance of ``Recty`` corresponding to the derived class. +It returns an instance of ``RecTy`` corresponding to the derived class. Some of the ``get()`` functions require an argument to specify which particular variant of the type is desired. These arguments are described in the following subsections. @@ -354,12 +354,12 @@ The class provides many additional functions: * Functions to determine whether there are any operands and to get the number of operands. -* Functions to the get the operands, both individually and together. +* Functions to get the operands, both individually and together. * Functions to determine whether there are any names and to get the number of names -* Functions to the get the names, both individually and together. +* Functions to get the names, both individually and together. * Functions to get the operand iterator ``begin()`` and ``end()`` values. @@ -605,7 +605,7 @@ null if the field does not exist. The field is assumed to have another record as its value. That record is returned as a pointer to a ``Record``. If the field does not exist or is unset, the -functions returns null. +function returns null. Getting Record Superclasses =========================== diff --git a/llvm/docs/WritingAnLLVMBackend.rst b/llvm/docs/WritingAnLLVMBackend.rst index 3c5d594..cab6471 100644 --- a/llvm/docs/WritingAnLLVMBackend.rst +++ b/llvm/docs/WritingAnLLVMBackend.rst @@ -150,7 +150,7 @@ any other naming scheme will confuse ``llvm-config`` and produce a lot of To make your target actually do something, you need to implement a subclass of ``TargetMachine``. This implementation should typically be in the file ``lib/Target/DummyTargetMachine.cpp``, but any file in the ``lib/Target`` -directory will be built and should work. To use LLVM's target independent code +directory will be built and should work. To use LLVM's target-independent code generator, you should do what all current machine backends do: create a subclass of ``CodeGenTargetMachineImpl``. (To create a target from scratch, create a subclass of ``TargetMachine``.) @@ -1671,7 +1671,7 @@ For example in ``SparcTargetAsmInfo.cpp``: } The X86 assembly printer implementation (``X86TargetAsmInfo``) is an example -where the target specific ``TargetAsmInfo`` class uses an overridden methods: +where the target-specific ``TargetAsmInfo`` class uses an overridden methods: ``ExpandInlineAsm``. A target-specific implementation of ``AsmPrinter`` is written in diff --git a/llvm/docs/WritingAnLLVMPass.rst b/llvm/docs/WritingAnLLVMPass.rst index 9c2c383..eec9887 100644 --- a/llvm/docs/WritingAnLLVMPass.rst +++ b/llvm/docs/WritingAnLLVMPass.rst @@ -431,7 +431,7 @@ The ``print`` method virtual void print(llvm::raw_ostream &O, const Module *M) const; The ``print`` method must be implemented by "analyses" in order to print a -human readable version of the analysis results. This is useful for debugging +human-readable version of the analysis results. This is useful for debugging an analysis itself, as well as for other people to figure out how an analysis works. Use the opt ``-analyze`` argument to invoke this method. diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst index 7b9105b..a739936 100644 --- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst +++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst @@ -129,7 +129,7 @@ course, C source code is not actually portable in general either - ever port a really old application from 32- to 64-bits?). The problem with C (again, in its full generality) is that it is heavily -laden with target specific assumptions. As one simple example, the +laden with target-specific assumptions. As one simple example, the preprocessor often destructively removes target-independence from the code when it processes the input text: |