LLVM 18.0.0git Release Notes¶
These are in-progress notes for the upcoming LLVM 18 release. Release notes for previous releases can be found on the Download Page.
This document contains the release notes for the LLVM Compiler Infrastructure, release 18.0.0git. 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.
For more information about LLVM, including information about the latest release, please check out the main LLVM web site. If you have questions or comments, the Discourse forums 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.
The llvm.stacksave and llvm.stackrestore intrinsics now use an overloaded pointer type to support non-0 address spaces.
The constant expression variants of the following instructions have been removed:
Added llvm.exp10 intrinsic.
llvm.sqrt.f32 is now lowered correctly. Use llvm.amdgcn.sqrt.f32 for raw instruction access.
Implemented llvm.stacksave and llvm.stackrestore intrinsics.
Zihintntl extension version was upgraded to 1.0 and is no longer experimental.
The LLVM filesystem class
equivalent()no longer determine that distinct different path names for the same hard linked file actually are equal. This is an intentional tradeoff in a bug fix, where the bug used to cause distinct files to be considered equivalent on some file systems. This change fixed the issues https://github.com/llvm/llvm-project/issues/61401 and https://github.com/llvm/llvm-project/issues/22079.
The python bindings have been removed.
LLVMSetTailCallKindto allow getting and setting
notailattributes on call instructions.
The following functions for creating constant expressions have been removed, because the underlying constant expressions are no longer supported. Instead, an instruction should be created using the
LLVMBuildXYZAPIs, which will constant fold the operands if possible and create an instruction otherwise:
PrologEpilogInserterno longer supports register scavenging during forwards frame index elimination. Targets should use backwards frame index elimination instead.
RegScavengerno longer supports forwards register scavenging. Clients should use backwards register scavenging instead, which is preferred because it does not depend on accurate kill flags.
llvm-symbolizer now treats invalid input as an address for which source information is not found.
llvm-readelf now supports
-X) to display extra information (section name) when showing symbols.
llvm-nmnow supports the
-l) option to use debugging information to print symbols’ filenames and line numbers.
Methods in SBHostOS related to threads have had their implementations removed. These methods will return a value indicating failure.
HWASan now defaults to detecting use-after-scope bugs.
llvm::opt::Optionhas been split into
Visibilityto simplify option sharing between various drivers (such as
flang) that rely on Clang’s Options.td. Overloads of
FlagsToIncludehave been deprecated. There is a script and instructions on how to resolve conflicts - see https://reviews.llvm.org/D157150 and https://reviews.llvm.org/D157151 for details.
On Linux, FreeBSD, and NetBSD, setting the environment variable
LLVM_ENABLE_SYMBOLIZER_MARKUPcauses tools to print stacktraces using Symbolizer Markup. This works even if the tools have no embedded symbol information (i.e. are fully stripped); llvm-symbolizer can symbolize the markup afterwards using
A wide variety of additional information is available on the LLVM web page, in particular in the documentation 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.