mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 06:36:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/llvm/docs/ReleaseNotes.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

362 lines
13 KiB
Markdown
Raw Normal View History

[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
<!-- This document is written in Markdown and uses extra directives provided by
MyST (https://myst-parser.readthedocs.io/en/latest/). -->
LLVM {{env.config.release}} Release Notes
=========================================
```{contents}
```
````{only} PreRelease
```{warning} These are in-progress notes for the upcoming LLVM {{env.config.release}}
release. Release notes for previous releases can be found on
[the Download Page](https://releases.llvm.org/download.html).
```
````
Introduction
============
This document contains the release notes for the LLVM Compiler Infrastructure,
release {{env.config.release}}. Here we describe the status of LLVM, including
major improvements from the previous release, improvements in various subprojects
of LLVM, and some of the current users of the code. All LLVM releases may be
downloaded from the [LLVM releases web site](https://llvm.org/releases/).
For more information about LLVM, including information about the latest
release, please check out the [main LLVM web site](https://llvm.org/). If you
have questions or comments, the [Discourse forums](https://discourse.llvm.org)
is a good place to ask them.
Note that if you are reading this file from a Git checkout or the main
LLVM web page, this document applies to the *next* release, not the current
one. To see the release notes for a specific release, please see the
[releases page](https://llvm.org/releases/).
Non-comprehensive list of changes in this release
=================================================
<!-- For small 1-3 sentence descriptions, just add an entry at the end of
this list. If your description won't fit comfortably in one bullet
point (e.g. maybe you would like to give an example of the
functionality, or simply have a lot to talk about), see the comment below
for adding a new subsection. -->
Reland "[LLVM] Add IRNormalizer Pass" (#113780) `IRNormalizer` will reorder instructions. Thus, we need to invalidate analyses. Done in cd500d28cba3177c213f2f2faf50f14ea56e230b. This should resolve the [BuildBot failure](https://github.com/llvm/llvm-project/pull/68176#issuecomment-2428243474). --- Original PR: #68176 Original commit: 1295d2e6da2fe90f3b770ab1d35bf5caecd38bed Reverted with: 8a12e0131f3d84b470fac63af042aa96a1b19f56 --- Add the llvm-canon tool. Description from the [original PR](https://reviews.llvm.org/D66029#change-wZv3yOpDdxIu): > Added a new llvm-canon tool which aims to transform LLVM Modules into a canonical form by reordering and renaming instructions while preserving the same semantics. This tool makes it easier to spot semantic differences while diffing two modules which have undergone different transformation passes. The current version of this tool can: - Reorder instructions within a function. - Rename instructions based on the operands. - Sort commutative operands. This code was originally written by @michalpaszkowski and [submitted to mainline LLVM](https://github.com/llvm/llvm-project/commit/14d358537f124a732adad1ec6edf3981dc9baece). However, it was quickly [reverted](https://github.com/llvm/llvm-project/commit/335de55fa3384946f1e62050f2545c0966163236) to do BuildBot errors. Michal presented his version of the tool in [LLVM-Canon: Shooting for Clear Diffs](https://www.youtube.com/watch?v=c9WMijSOEUg). @AidanGoldfarb and I ported the code to the new pass manager, added more tests, and fixed some bugs related to PHI nodes that may have been the root cause of the BuildBot errors that caused the patch to be reverted. Additionally, we rewrote the implementation of instruction reordering to fix cases where the original algorithm would break use-def chains. Note that this is @AidanGoldfarb and I's first time submitting to LLVM. Please liberally critique the PR! CC @plotfi for initial review. --------- Co-authored-by: Aidan <aidan.goldfarb@mail.mcgill.ca>
2024-11-14 09:56:22 -08:00
* Added a new IRNormalizer pass which aims to transform LLVM modules into
a normal form by reordering and renaming instructions while preserving the
same semantics. The normalizer makes it easier to spot semantic differences
when diffing two modules which have undergone different passes.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
* ...
<!-- If you would like to document a larger change, then you can add a
subsection about it right here. You can copy the following boilerplate:
Special New Feature
-------------------
Makes programs 10x faster by doing Special New Thing.
-->
Changes to the LLVM IR
----------------------
[IR] Disallow recursive types (#114799) StructType::setBody is the only mechanism that can potentially create recursion in the type system. Add a runtime check that it is not actually used to create recursion. If the check fails, report an error from LLParser, BitcodeReader and IRLinker. In all other cases assert that the check succeeds. In future StructType::setBody will be removed in favor of specifying the body when the type is created, so any performance hit from this runtime check will be temporary.
2024-11-05 09:41:10 +00:00
* Types are no longer allowed to be recursive.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
* The `x86_mmx` IR type has been removed. It will be translated to
the standard vector type `<1 x i64>` in bitcode upgrade.
* Renamed `llvm.experimental.stepvector` intrinsic to `llvm.stepvector`.
* Added `usub_cond` and `usub_sat` operations to `atomicrmw`.
[RFC] IR: Define noalias.addrspace metadata (#102461) This is intended to solve a problem with lowering atomics in OpenMP and C++ common to AMDGPU and NVPTX. In OpenCL and CUDA, it is undefined behavior for an atomic instruction to modify an object in thread private memory. In OpenMP, it is defined. Correspondingly, the hardware does not handle this correctly. For AMDGPU, 32-bit atomics work and 64-bit atomics are silently dropped. We therefore need to codegen this by inserting a runtime address space check, performing the private case without atomics, and fallback to issuing the real atomic otherwise. This metadata allows us to avoid this extra check and branch. Handle this by introducing metadata intended to be applied to atomicrmw, indicating they cannot access the forbidden address space.
2024-10-07 23:21:42 +04:00
* Introduced `noalias.addrspace` metadata.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
* Remove the following intrinsics which can be replaced with a `bitcast`:
* `llvm.nvvm.bitcast.f2i`
* `llvm.nvvm.bitcast.i2f`
* `llvm.nvvm.bitcast.d2ll`
* `llvm.nvvm.bitcast.ll2d`
* Remove the following intrinsics which can be replaced with a funnel-shift:
* `llvm.nvvm.rotate.b32`
* `llvm.nvvm.rotate.right.b64`
* `llvm.nvvm.rotate.b64`
* Remove the following intrinsics which can be replaced with an
`addrspacecast`:
* `llvm.nvvm.ptr.gen.to.global`
* `llvm.nvvm.ptr.gen.to.shared`
* `llvm.nvvm.ptr.gen.to.constant`
* `llvm.nvvm.ptr.gen.to.local`
* `llvm.nvvm.ptr.global.to.gen`
* `llvm.nvvm.ptr.shared.to.gen`
* `llvm.nvvm.ptr.constant.to.gen`
* `llvm.nvvm.ptr.local.to.gen`
[NVPTX] Remove nvvm.ldg.global.* intrinsics (#112834) Remove these intrinsics which can be better represented by load instructions with `!invariant.load` metadata: - llvm.nvvm.ldg.global.i - llvm.nvvm.ldg.global.f - llvm.nvvm.ldg.global.p
2024-10-27 16:14:13 -07:00
* Remove the following intrinsics which can be relaced with a load from
addrspace(1) with an !invariant.load metadata
* `llvm.nvvm.ldg.global.i`
* `llvm.nvvm.ldg.global.f`
* `llvm.nvvm.ldg.global.p`
[IR] Allow MDString in operand bundles (#110805) This change implements support of metadata strings in operand bundle values. It makes possible calls like: call void @some_func(i32 %x) [ "foo"(i32 42, metadata !"abc") ] It requires some extension of the bitcode serialization. As SSA values and metadata are stored in different tables, there must be a way to distinguish them during deserialization. It is implemented by putting a special marker before the metadata index. The marker cannot be treated as a reference to any SSA value, so it unambiguously identifies metadata. It allows extending the bitcode serialization without breaking compatibility. Metadata as operand bundle values are intended to be used in floating-point function calls. They would represent the same information as now is passed by the constrained intrinsic arguments.
2024-10-11 12:09:10 +07:00
* Operand bundle values can now be metadata strings.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to LLVM infrastructure
------------------------------
Changes to building LLVM
------------------------
Changes to TableGen
-------------------
Changes to Interprocedural Optimizations
----------------------------------------
Changes to the AArch64 Backend
------------------------------
* `.balign N, 0`, `.p2align N, 0`, `.align N, 0` in code sections will now fill
the required alignment space with a sequence of `0x0` bytes (the requested
fill value) rather than NOPs.
[NFC][AArch64][LLVM] Update ReleaseNotes.md with Armv9.6-A (2024) arch extensions
2024-10-25 14:54:56 +01:00
* Assembler/disassembler support has been added for Armv9.6-A (2024)
architecture extensions.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the AMDGPU Backend
-----------------------------
* Removed `llvm.amdgcn.flat.atomic.fadd` and
`llvm.amdgcn.global.atomic.fadd` intrinsics. Users should use the
{ref}`atomicrmw <i_atomicrmw>` instruction with `fadd` and
addrspace(0) or addrspace(1) instead.
Changes to the ARM Backend
--------------------------
* `.balign N, 0`, `.p2align N, 0`, `.align N, 0` in code sections will now fill
the required alignment space with a sequence of `0x0` bytes (the requested
fill value) rather than NOPs.
[ARM] Fix -mno-omit-leaf-frame-pointer flag doesn't works on 32-bit ARM (#109628) The -mno-omit-leaf-frame-pointer flag works on 32-bit ARM architectures and addresses the bug reported in #108019
2024-10-17 20:25:06 +08:00
* The default behavior for frame pointers in leaf functions has been updated.
When the `-fno-omit-frame-pointer` option is specified, `FPKeepKindStr` is
set to `-mframe-pointer=all`, meaning the frame pointer (FP) is now retained
in leaf functions by default. To eliminate the frame pointer in leaf functions,
you must explicitly use the `-momit-leaf-frame-pointer` option.
Reland "[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions. (PR #111970)" (#112877) **Change relanded after feedback on failures and improvements to the check of the addend. Original PR #111970** Changes from original patch: - The value that is being checked has changed, it is now correctly checking any Addend for the instruction, rather than the Value. The addend is kept within the Target data structure from my investigation. - Removed changes to the following tests due to the original behaviour being correct, and my original patch causing unexpected errors - llvm/test/MC/ARM/Windows/mov32t-range.s - llvm/test/MC/MachO/ARM/thumb2-movw-fixup.s As per the ARM ABI, the MOVT and MOVW instructions should have addends that fall within a 16bit signed range. LLVM does not check this so it is possible to use addends that are beyond the accepted range. These addends are silently truncated. A new check is added to ensure the addend falls within the expected range, rejecting an addend that falls outside with an error. Information relating to the ABI requirements can be found here: https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#addends-and-pc-bias-compensation
2024-10-22 08:18:09 +01:00
* When using the `MOVT` or `MOVW` instructions, the Assembler will now check to
ensure that any addend that is used is within a 16-bit signed value range. If the
addend falls outside of this range, the LLVM backend will emit an error like so
`Relocation Not In Range`.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the AVR Backend
--------------------------
Changes to the DirectX Backend
------------------------------
Changes to the Hexagon Backend
------------------------------
Changes to the LoongArch Backend
--------------------------------
Changes to the MIPS Backend
---------------------------
Changes to the PowerPC Backend
------------------------------
[PowerPC][LLC] Utilize PPC::getNormalizedPPCTargetCPU() to set CPU (#113943) Utilize common API in PPCTargetParser (https://github.com/llvm/llvm-project/pull/97541) to set default CPU with same interfaces for LLC. This will update AIX default CPU to pwr7 and LoP powerppc64 default CPU to ppc64.
2024-11-04 09:40:54 -05:00
* The Linux `ppc64` LLC default cpu is updated from `ppc` to `ppc64`.
* The AIX LLC default cpu is updated from `generic` to `pwr7`.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the RISC-V Backend
-----------------------------
* `.balign N, 0`, `.p2align N, 0`, `.align N, 0` in code sections will now fill
the required alignment space with a sequence of `0x0` bytes (the requested
fill value) rather than NOPs.
* Added Syntacore SCR4 and SCR5 CPUs: `-mcpu=syntacore-scr4/5-rv32/64`
* `-mcpu=sifive-p470` was added.
* Added Hazard3 CPU as taped out for RP2350: `-mcpu=rp2350-hazard3` (32-bit
only).
* Fixed length vector support using RVV instructions now requires VLEN>=64. This
means Zve32x and Zve32f will also require Zvl64b. The prior support was
largely untested.
* The `Zvbc32e` and `Zvkgs` extensions are now supported experimentally.
[RISCV]Add svvptc extension (#113882)
2024-10-28 04:54:51 -07:00
* Added `Smctr`, `Ssctr` and `Svvptc` extensions.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
* `-mcpu=syntacore-scr7` was added.
* The `Zacas` extension is no longer marked as experimental.
[RISCV] Add Smdbltrp and Ssdbltrp extension (#111837) Smdbltrp and Ssdbltrp supports are added in this PR. Specification link(Smdbltrp) : [https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltrp.adoc](url) Specification link(Ssdbltrp) : [https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc](url)
2024-11-08 15:01:51 +08:00
* Added Smdbltrp, Ssdbltrp extensions to -march.
[RISCV] Mark pointer masking extensions as non-experimental (#113618) These extensions were ratified very recently. <https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154732/Ratified+Extensions> I've ensured we have definitions for all extensions in the document <https://drive.google.com/file/d/159QffOTbi3EEbdkKndYRZ2c46D25ZLmO/view?usp=drive_link>. There are no additional CSRs.
2024-10-25 04:24:50 -07:00
* The `Smmpm`, `Smnpm`, `Ssnpm`, `Supm`, and `Sspm` pointer masking extensions
are no longer marked as experimental.
[RISCV] Add the Sha extension (#113820) This was introduced in the now-ratified RVA23 profile (and also added to the RVA22 text) as a simple way of referring to H plus the set of supervisor extensions required by RVA23. https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc This patch simply defines the extension. The next patch will adjust the RVA23 profile to use it, and at that point I think we will be ready to mark RVA23 as non-experimental. Note that I haven't made it so if you enable all extensions that constitute Sha, Sha is implied. Per #76893 (adding 'B'), the concern is making this implication might break older external assemblers. Perhaps this is less of a concern given the relative frequency of `-march=${foo}_zba_zbb_zbs` vs the collection of H extensions. If we did want to add that implication, we'd probably want to add it in a separate patch so it can be easily reverted if found to cause problems.
2024-10-28 07:42:33 +00:00
* The `Sha` extension is now supported.
[RISCV] Mark RVB23U64 and RVB23S64 as non-experimental (#113918) The specification was recently ratified <https://github.com/riscv/riscv-profiles/blob/main/src/rvb23-profile.adoc>.
2024-10-29 07:57:34 +00:00
* The RVA23U64, RVA23S64, RVB23U64, and RVB23S64 profiles are no longer marked
as experimental.
[RISCV][docs] Release Notes These cover recent additions and changes to assembly and inline assembly support.
2024-11-18 11:01:44 -08:00
* `.insn <length>, <raw encoding>` can be used to assemble 48- and 64-bit
instructions from raw integer values.
* `.insn [<length>,] <raw encoding>` now accepts absolute expressions for both
expressions, so that they can be computed from constants and absolute symbols.
* The following new inline assembly constraints and modifiers are accepted:
* `cr` constraint meaning an RVC-encoding compatible GPR (`x8`-`x15`)
* `cf` constraint meaning an RVC-encoding compatible FPR (`f8`-`f15`)
* `R` constraint meaning an even-odd GPR pair (prints as the even register,
but both registers in the pair are considered live).
* `N` modifer meaning print the register encoding (0-31) rather than the name.
* `f` and `cf` inline assembly constraints, when using F-/D-/H-in-X extensions,
will use the relevant GPR rather than FPR. This makes inline assembly portable
between e.g. F and Zfinx code.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the WebAssembly Backend
----------------------------------
[WebAssembly] Enable nontrapping-fptoint and bulk-memory by default. (#112049) We were prepared to enable these features [back in February], but they got pulled for what appear to be unrelated reasons. So let's have another try at enabling them! Another motivation here is that it'd be convenient for the [Lime1 proposal] if "lime1" is close to a subset of "generic" (missing only for extended-const). [back in February]: https://github.com/WebAssembly/tool-conventions/issues/158#issuecomment-1931119512 [Lime1 proposal]: https://github.com/llvm/llvm-project/pull/112035
2024-10-25 13:52:51 -07:00
The default target CPU, "generic", now enables the `-mnontrapping-fptoint`
and `-mbulk-memory` flags, which correspond to the [Bulk Memory Operations]
and [Non-trapping float-to-int Conversions] language features, which are
[widely implemented in engines].
[Bulk Memory Operations]: https://github.com/WebAssembly/bulk-memory-operations/blob/master/proposals/bulk-memory-operations/Overview.md
[Non-trapping float-to-int Conversions]: https://github.com/WebAssembly/spec/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md
[widely implemented in engines]: https://webassembly.org/features/
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the Windows Target
-----------------------------
Changes to the X86 Backend
--------------------------
* `.balign N, 0x90`, `.p2align N, 0x90`, and `.align N, 0x90` in code sections
now fill the required alignment space with repeating `0x90` bytes, rather than
using optimised NOP filling. Optimised NOP filling fills the space with NOP
instructions of various widths, not just those that use the `0x90` byte
encoding. To use optimised NOP filling in a code section, leave off the
"fillval" argument, i.e. `.balign N`, `.p2align N` or `.align N` respectively.
* Due to the removal of the `x86_mmx` IR type, functions with
`x86_mmx` arguments or return values will use a different,
incompatible, calling convention ABI. Such functions are not
generally seen in the wild (Clang never generates them!), so this is
not expected to result in real-world compatibility problems.
* Support ISA of `AVX10.2-256` and `AVX10.2-512`.
[X86] Support MOVRS and AVX10.2 instructions. (#113274) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368
2024-10-25 09:00:19 +08:00
* Supported instructions of `MOVRS AND AVX10.2`
[X86] Support SM4 EVEX version intrinsics/instructions. (#113402) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368
2024-10-28 10:46:16 +08:00
* Supported ISA of `SM4(EVEX)`.
[X86][MC] Support instructions of MSR_IMM (#113524) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368
2024-10-28 12:59:51 +08:00
* Supported ISA of `MSR_IMM`.
Reland "[X86] Support -march=diamondrapids (#113881)" (#116564) Ref.: https://cdrdv2.intel.com/v1/dl/getContent/671368
2024-11-18 10:40:32 +08:00
* Supported ``-mcpu=diamondrapids``
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to the OCaml bindings
-----------------------------
Changes to the Python bindings
------------------------------
Changes to the C API
--------------------
* The following symbols are deleted due to the removal of the `x86_mmx` IR type:
* `LLVMX86_MMXTypeKind`
* `LLVMX86MMXTypeInContext`
* `LLVMX86MMXType`
* The following functions are added to further support non-null-terminated strings:
* `LLVMGetNamedFunctionWithLength`
* `LLVMGetNamedGlobalWithLength`
* The following functions are added to access the `LLVMContextRef` associated
with `LLVMValueRef` and `LLVMBuilderRef` objects:
* `LLVMGetValueContext`
* `LLVMGetBuilderContext`
* The new pass manager can now be invoked with a custom alias analysis pipeline, using
the `LLVMPassBuilderOptionsSetAAPipeline` function.
* It is now also possible to run the new pass manager on a single function, by calling
`LLVMRunPassesOnFunction` instead of `LLVMRunPasses`.
* Support for creating instructions with custom synchronization scopes has been added:
* `LLVMGetSyncScopeID` to map a synchronization scope name to an ID.
* `LLVMBuildFenceSyncScope`, `LLVMBuildAtomicRMWSyncScope` and
`LLVMBuildAtomicCmpXchgSyncScope` versions of the existing builder functions
with an additional synchronization scope ID parameter.
* `LLVMGetAtomicSyncScopeID` and `LLVMSetAtomicSyncScopeID` to get and set the
synchronization scope of any atomic instruction.
* `LLVMIsAtomic` to check if an instruction is atomic, for use with the above functions.
Because of backwards compatibility, `LLVMIsAtomicSingleThread` and
`LLVMSetAtomicSingleThread` continue to work with any instruction type.
* The `LLVMSetPersonalityFn` and `LLVMSetInitializer` APIs now support clearing the
personality function and initializer respectively by passing a null pointer.
* The following functions are added to allow iterating over debug records attached to
instructions:
* `LLVMGetFirstDbgRecord`
* `LLVMGetLastDbgRecord`
* `LLVMGetNextDbgRecord`
* `LLVMGetPreviousDbgRecord`
* Added `LLVMAtomicRMWBinOpUSubCond` and `LLVMAtomicRMWBinOpUSubSat` to `LLVMAtomicRMWBinOp` enum for AtomicRMW instructions.
Changes to the CodeGen infrastructure
-------------------------------------
Changes to the Metadata Info
---------------------------------
Changes to the Debug Info
---------------------------------
Changes to the LLVM tools
---------------------------------
Changes to LLDB
---------------------------------
[lldb][AArch64] Add release note for AArch64 Linux FPMR register
2024-09-27 16:44:05 +01:00
* LLDB can now read the `fpmr` register from AArch64 Linux processes and core
files.
[lldb] Fix write only file action to truncate the file (#112657) When `FileAction` opens file with write access, it doesn't clear the file nor append to the end of the file if it already exists. Instead, it writes from cursor index 0. For example, by using the settings `target.output-path` and `target.error-path`, lldb will redirect process stdout/stderr to files. It then calls this function to write to the files which the above symptoms appear. ## Test - Added unit test checking the file flags - Added 2 api tests checking - File content overwritten if the file path already exists - Stdout and stderr redirection to the same file doesn't change its behavior
2024-10-29 14:22:51 -04:00
* Program stdout/stderr redirection will now open the file with O_TRUNC flag, make sure to truncate the file if path already exists.
* eg. `settings set target.output-path/target.error-path <path/to/file>`
[lldb][AArch64] Add release note for AArch64 Linux FPMR register
2024-09-27 16:44:05 +01:00
[LLDB] Retry Add a target.launch-working-dir setting This retries the PR 113521 skipping a test in a remote environment.
2024-11-05 13:26:59 -05:00
* A new setting `target.launch-working-dir` can be used to set a persistent cwd that is used by default by `process launch` and `run`.
[llvm][docs] Convert LLVM release notes to Markdown (#109107) * Markdown is the most common format on GitHub and most contributors are more familiar with it than RST. * This leads to mistakes in the RST syntax and/or folks just using Markdown syntax and assuming it works. * The release notes have a high number of edits and a high number of views, we should optimise for making the common path easy. That is, adding a bullet point and a link. * Though GitHub can render RST and Markdown, its support for Markdown is more complete (and neither handle the Sphinx directives well). * We already have some Markdown docs in the llvm docs. To keep the original formatting we do need some Sphinx directives still, and those are provided by MyST which is already enabled. https://myst-parser.readthedocs.io/en/latest/ I did have to enable an extension so we can substitute in the release version. https://myst-parser.readthedocs.io/en/latest/syntax/optional.html#substitutions-with-jinja2 Needing to use MyST means there is some special knowledge needed if you want to do advanced things, but at least the basics remain Markdown. Even in RST form, you still had to look up Sphinx syntax. I also make use of a nested directive https://myst-parser.readthedocs.io/en/latest/syntax/roles-and-directives.html#nesting-directives to implement the prerelease warning. The note about sections referred to another note that got removed in 4c72deb613d9d8838785b431facb3eb480fb2f51. I presume accidentally, so I have restored that. I also removed the "Update on required toolchains to build LLVM" header because the section is now empty. The other difference is that the table of contents now has a heading "Contents". This is the default and I could not find a way to remove that name. Otherwise it's the same table as you'd get from the RST document.
2024-09-26 14:15:53 +01:00
Changes to BOLT
---------------------------------
Changes to Sanitizers
---------------------
Other Changes
-------------
External Open Source Projects Using LLVM {{env.config.release}}
===============================================================
* A project...
Additional Information
======================
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
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.
If you have any questions or comments about LLVM, please feel free to contact
us via the [Discourse forums](https://discourse.llvm.org).
Reference in New Issue Copy Permalink