1<!DOCTYPE html> 2<html> 3 <head> 4 <meta charset="UTF-8" /> 5 <meta name="viewport" content="width=device-width, initial-scale=1.0" /> 6 <title>This year in LLVM (2025)</title> 7 <link rel="stylesheet" href="/asset/reset.css" /> 8 <link rel="stylesheet" href="/asset/main.css" /> 9 <link rel="stylesheet" href="/asset/highlight.css" /> 10 <link rel="alternate" type="application/rss+xml" href="/rss.xml" /> 11 <link rel="canonical" href="https://www.npopov.com/2026/01/31/This-year-in-LLVM-2025.html" /> 12 <!-- Google tag (gtag.js) -->
vendor: 72 bytes, lines 12-13
12 13 <script async src="https://www.googletagmanager.com/gtag/js?id=
13G-69DTLTFJ7P
vendor: 20 bytes, lines 13-14
13"></script> 14
14<script> 15
vendor: 158 bytes, lines 15-19
15window.dataLayer = window.dataLayer || []; 16 function gtag(){dataLayer.push(arguments);} 17 gtag('js', new Date()); 18 19 gtag('config', '
19G-69DTLTFJ7P
vendor: 12 bytes, lines 19-20
19'); 20
20</script>
20 21 </head> 22 <body> 23 <header> 24 Blog by <strong>nikic</strong>. 25 Find me on <a href="https://github.com/nikic">GitHub</a>, 26 <a href="https://stackoverflow.com/users/385378/nikic">StackOverflow</a>, 27 <a href="http://twitter.com/nikita_ppv">Twitter</a> and 28 <a rel="me" href="https://mastodon.social/@nikic">Mastodon</a>. 29 Learn more <a href="/aboutMe.html">about me</a>. 30 </header> 31 <section> 32 33<section class="post"> 34 <header> 35 <a href="/" class="backLink">« Back to article overview.</a> 36 <h1>This year in LLVM (2025)</h1> 37 <time datetime="2026-01-31" pubdate> 38 31. January 2026 39 </time> 40 41 </header> 42 <section> 43 44 <p>Itâs 2026, so itâs time for my yearly summary blog post. Iâm a bit late, but at least itâs still January! As usual, this summary is about my own work, and only covers the more significant / higher-level items.</p> 45 46<p>Previous years: <a href="https://www.npopov.com/2025/01/05/This-year-in-LLVM-2024.html">2024</a>, <a href="https://www.npopov.com/2024/01/01/This-year-in-LLVM-2023.html">2023</a>, <a href="https://www.npopov.com/2022/12/20/This-year-in-LLVM-2022.html">2022</a></p> 47 48<h2 id="ptradd">ptradd</h2> 49 50<p>I have been making slow progress on the <a href="https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699?u=nikic">ptradd migration</a> over the last three years. The goal of this change is to move away from the type-based <code class="language-plaintext highlighter-rouge">getelementptr</code> (GEP) representation, towards a <code class="language-plaintext highlighter-rouge">ptradd</code> instruction, which just adds an integer offset to a pointer.</p> 51 52<p>The state at the start of the year was that constant-offset GEP instructions were canonicalized to the form <code class="language-plaintext highlighter-rouge">getelementptr i8, ptr %p, i64 OFFSET</code>, which is equivalent to a <code class="language-plaintext highlighter-rouge">ptradd</code>.</p> 53 54<p>The progress this year was to canonicalize all GEP instructions to have a single offset. For example, <code class="language-plaintext highlighter-rouge">getelementptr [10 x i32], ptr %p, i64 %a, i64 %b</code> gets split into two instructions now. This moves us closer to <code class="language-plaintext highlighter-rouge">ptradd</code>, which only accepts a single offset argument. However, the change is also independently useful, because it allows CSE of common GEP prefixes.</p> 55 56<p>This work happened in multiple phases, first splitting <a href="https://github.com/llvm/llvm-project/pull/137297">multiple variable indices</a>, then splitting off <a href="https://github.com/llvm/llvm-project/pull/151333">constant indices as well</a> and finally removing <a href="https://github.com/llvm/llvm-project/pull/155415">leading zero indices</a>.</p> 57 58<p>As usual, the bulk of the work was not in the changes themselves, but in mitigating resulting regressions. Many transforms were extended to work on chains of GEPs rather than only a single one. Once again, this is also useful independently of the ptradd migration, as chained GEPs were already very common beforehand.</p> 59 60<p>There are still some major remaining pieces of work to complete this migration. The first one is to decide whether we want <code class="language-plaintext highlighter-rouge">ptradd</code> to support a constant scaling factor, or require it to be represented using a separate multiplication. There are good arguments in favor of both options.</p> 61 62<p>The second one is to move from mere canonicalization towards requiring the new form. This would probably involve first making IRBuilder emit it, and then actually preventing construction of the type-based form. That would be the point where weâd actually introduce the <code class="language-plaintext highlighter-rouge">ptradd</code> instruction.</p> 63 64<h2 id="ptrtoaddr">ptrtoaddr</h2> 65 66<p>LLVM 22 <a href="https://github.com/llvm/llvm-project/pull/139357">introduces</a> a new <code class="language-plaintext highlighter-rouge">ptrtoaddr</code> instruction. This is the outcome of a <a href="https://discourse.llvm.org/t/clarifiying-the-semantics-of-ptrtoint/83987?u=nikic">long discussion</a> on the semantics of <code class="language-plaintext highlighter-rouge">ptrtoint</code> and pointer comparisons for <a href="https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instru
66ctions">CHERI architectures</a>.</p> 67 68<p>The semantics of <code class="language-plaintext highlighter-rouge">ptrtoaddr</code> are similar to <code class="language-plaintext highlighter-rouge">ptrtoint</code>, but differ in two respects:</p> 69 70<ul> 71 <li>It does not expose the provenance of the pointer. In Rust terms, it corresponds to <code class="language-plaintext highlighter-rouge">addr()</code> instead of <code class="language-plaintext highlighter-rouge">expose_provenance()</code>.</li> 72 <li>It returns only the address portion of the pointer. This matters for CHERI, where pointers also carry additional metadata bits.</li> 73</ul> 74 75<p>A non-exposing way to convert a pointer into an integer is an important step towards figuring out LLVMâs provenance story. LLVM currently ignores the fact that <code class="language-plaintext highlighter-rouge">ptrtoint</code> has an (exposure) side-effect, and having a side-effect-free alternative is one of the prerequisites to actually taking this seriously. (The other is the <a href="https://discourse.llvm.org/t/rfc-add-a-new-byte-type-to-llvm-ir/89522?u=nikic">byte type</a>.)</p> 76 77<p>The downside of having two instructions that do something similar but not quite the same is that it requires careful adjustment of existing optimizations to work on both forms, where possible. This is something I have been working on, and <code class="language-plaintext highlighter-rouge">ptrtoaddr</code> should now be supported in most of the important optimizations.</p> 78 79<h2 id="lifetime-intrinsics">Lifetime intrinsics</h2> 80 81<p>LLVM represents stack allocations using <code class="language-plaintext highlighter-rouge">alloca</code> instructions. These are generally always placed inside the entry block, while the actual lifetime of the allocation is marked using <a href="https://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic"><code class="language-plaintext highlighter-rouge">lifetime.start</code></a> and <a href="https://llvm.org/docs/LangRef.html#llvm-lifetime-end-intrinsic"><code class="language-plaintext highlighter-rouge">lifetime.end</code></a> intrinsics. The primary purpose of these intrinsics is to enable stack coloring, which can place stack allocations that are not live at the same time at the same address, greatly reducing stack usage.</p> 82 83<p>I have made two major changes to lifetime intrinsics: The first is to enforce that they are <a href="https://github.com/llvm/llvm-project/pull/149310">only used with allocas</a>. Previously, it was possible to use them on arbitrary pointers, such as function arguments. This is incompatible with stack coloring, which requires that all lifetime markers for an allocation are visible â they canât be hidden behind a function call.</p> 84 85<p>Making this an IR validity requirement was helpful in uncovering quite a few cases where we ended up using lifetimes on non-allocas by mistake, as a result of optimization passes. Most commonly, the alloca was accidentally obscured by phi nodes.</p> 86 87<p>The second change was to <a href="https://github.com/llvm/llvm-project/pull/150248">remove the size argument</a> from lifetime intrinsics. In theory, this argument allowed you to control the lifetime of a subset of the allocation. In practice, this was never used, and stack coloring just ignored the argument. This was a smaller change in terms of IR semantics, but significantly larger in impact because it required updates to all code and tests involving lifetime intrinsics.</p> 88 89<p>While these changes have resolved some issues with our handling of lifetimes, more problems (with <a href="https://github.com/llvm/llvm-project/issues/51838">store speculation</a> and <a href="https://github.com/llvm/llvm-project/issues/45725">comparisons</a>) remain. A core issue is that in the current representation, itâs not possible to efficiently determine whether an alloca is live at a given point, or whether the lifetime of two allocas can overlap. Fixing this requires more intrusive changes.</p> 90 91<h2 id="capture-tracking">Capture tracking</h2> 92 93<p>Another piece of work that carried over from the previous year are improvements to capture tracking. I <a href="https://discourse.llvm.org/t/rfc-improvements-to-capture-tracking/81420?u=nikic">proposed</a> this last year, but the majority of the implementation work happened this year.</p> 94 95<p>The most important part of this proposal is that we now distinguish between capturing the address of a pointer, and its provenance. Many optimizations only care about the latter, because only provenance capture may result in non-analyzable memory effects.</p> 96 97<p>The most significant changes to enable this were <a href="https://github.com/llvm/llvm-project/pull/125880">inference support</a>, and updating alias analysis to only check for <a href="https://github.com/llvm/llvm-project/pull/130777">provenance captures</a> and make use of <a href="https://github.com/llvm/llvm-project/pull/143097">read-only captures</a>.</p> 98 99<p>Iâve also extended this feature by adding <a href="https://github.com/llvm/llvm-project/pull/160913"><code class="language-plaintext highlighter-rouge">!captures</code> metadata</a> on stores. This is intended to allow encoding that stores of non-mut references in Rust only capture read provenance, which is helpful to optimize around constructs like <code class="language-plaintext highlighter-rouge">println!()</code>, which capture via memory rather than function arguments. Whether we can actually do this depends on an <a href="https://github.com/rust-lang/unsafe-code-guidelines/issues/371">open question</a> in Rustâs aliasing model.</p> 100 101<h2 id="abi">ABI</h2> 102 103<p>One of the biggest failures of LLVM as an abstraction across different target architectures is its handling of platform ABIs, in the sense of calling conventions (CC). A large part of the ABI handling has to be performed in the frontend, which currently means that every frontend with C FFI support has to reimplement complex and subtle ABI rules for all targets it supports.</p> 104 105<p>To ameliorate this, I have proposed an <a href="https://discourse.llvm.org/t/rfc-an-abi-lowering-library-for-llvm/84495?u=nikic">ABI lowering library</a>, which tells frontends how to correctly lower a given function signature that is provided using a separate ABI type system, which is richer than LLVM IR types, but much simpler than Clang QualTypes.</p> 106 107<p>As part of GSoC, <a href="https://github.com/vortex73">vortex73</a> has implemented a <a href="https://github.com/llvm/llvm-project/pull/140112">prototype</a> for such a library. It demonstrates that the general approach works for the x86-64 SystemV ABI (one of the more complex ones), without significant overhead. For more information, see the accompanying <a href="https://blog.llvm.org/posts/2025-08-25-abi-library/">blog post</a>. Work to upstream this library is underway.</p> 108 109<p>Another pain point is that information on type alignment is duplicated between Clang and LLVM (for layering reasons), and this information can get out of sync. This causes issues for frontends like Rust, which use the LLVM information. Iâve implemented some <a href="https://github.com/llvm/llvm-project/pull/144720">consistency checks</a> to prevent more of these issues in the future. Iâve also <a href="https://github.com/llvm/llvm-project/pull/171135">removed</a> the duplicate data layout definitions between Clang and LLVM.</p> 110 111<p>Iâve also done some work to improve the backend side of things, by exposing the <a href="https://github.com/llvm/llvm-project/pull/152709">original, unlegalized argument type</a> to CC lowering. This allowed cleaning up lots of target-specific hacks, like MIPSâ hardcoded list of <a href="https://github.com/llvm/llvm-project/pull/153798">fp128 libcalls</a>.</p> 112 113<h2 id="constantint-assertions">ConstantInt assertions</h2> 114 115<p>The previous year, I introduced an assertion when constructing arbitrary-precision integers (APInts) from <code class="language-plaintext highlighter-rouge">uint64_t</code>, which ensures that the value actually is an N-bit signed/unsigned integer. The purpose of this assertion is to avoid miscompiles due to incorrectly specified signedness, which only manifests for large integers (with more than 64 bits).</p> 116 117<p>Back then, I excluded the <code class="language-plaintext highlighter-rouge">ConstantInt::get()</code> constructor from this assertion to reduce the (already very large) scope of the work. I ended up regretting that when I hit a <a href="https://github.com/llvm/llvm-project/pull/170860">SelectOptimize miscompile</a>, which is caused by precisely the problem this assertion is supposed to prevent.</p> 118 119<p>That was enough motivation to <a href="https://github.com/llvm/llvm-project/pull/171456">extend</a> the assertion to <code class="language-plaintext highlighter-rouge">ConstantInt::get()</code>. Once again, this required substantial work to fix existing issues (most of which were harmless, but Iâve caught at least two more miscompiles along the way).</p> 120 121<h2 id="compilation-time">Compilation-time</h2> 122 123<!-- 124http://localhost:8000/graphs.php?startDate=2025-01-01&endDate=2026-01-01&interval=25&relative=on&bench=geomean&width=800&configs=stage2-O3,stage2-O0-g 125legend: "always", 126top: 16em !important; 127left: 5.5em !important; 128--> 129 130<p>I have done little compile-time work this year, and there hasnât been much activity from other people either. Hereâs how compile-time developed over the course of 2025:</p> 131 132<p><img src="/images/llvm_geomean_2025.png" alt="LLVM geomean instruction count changes since January 2025" style="max-width: 100%" /></p> 133 134<p>I have only included two configurations in the graph, because it is getting quite cluttered otherwise. Historically, I have only been tracking compile-times on x86, but have added two AArch64 configurations this year. An interesting takeaway from this is that compilation for AArch64 is around 10-20% slower, depending on configuration. For unoptimized builds, this is due to use of GlobalISel instead of FastISel. For optimized builds, use of alias analysis during codegen is a significant factor.</p> 135 136<p>In terms of optimizations, Iâve implemented an improvement to <a href="https://github.com/llvm/llvm-project/commit/545cdca4883552b147a0f1adfac713f76fc22305">SCCP worklist management</a> (<a href="https://llvm-compile-time-tracker.com/compare.php?from=6f7370ced630ec1994456a979ca10ac26e3dc0a7&to=545cdca4883552b147a0f1adfac713f76fc22305&stat=instructions:u">~0.25% improvement</a>), which reduces the number of times instructions are visited during sparse conditional constant propagation. Iâve introduced a <a href="https://github.com/llvm/llvm-project/commit/a987022f33a27610732544b0c5f4475ce818c982">getBaseObjectSize()</a> function (<a href="https://github.com/llvm/llvm-project/commit/a987022f33a27610732544b0c5f4475ce818c982">
136~0.35% improvement</a>) to avoid use of expensive <code class="language-plaintext highlighter-rouge">__builtin_object_size</code> machinery where it is not needed. Iâve also specialized calculation of <a href="https://github.com/llvm/llvm-project/commit/4d927a5faf42d025410586f0cdc3bf60ef198a86">type allocation sizes</a> (<a href="https://llvm-compile-time-tracker.com/compare.php?from=34d4f0c13666ea25b4d27dcb96dfc70da005f286&to=4d927a5faf42d025410586f0cdc3bf60ef198a86&stat=instructions:u">~0.25% improvement</a>) to reduce redundant operations.</p> 137 138<p>Iâd also like to highlight two changes from other contributors. One was to optimize <a href="https://github.com/llvm/llvm-project/commit/26d9cb17a6e655993c991b66b21d5c378256d79b">debug linetable emission</a>, by avoiding the creation of unnecessary fragments. This improved debug builds by <a href="https://llvm-compile-time-tracker.com/compare.php?from=705e27c23474f3177670a791b5b54eefedee0cd8&to=26d9cb17a6e655993c991b66b21d5c378256d79b&stat=instructions:u">~1%</a>. Another was to change the representation of <a href="https://github.com/llvm/llvm-project/commit/91cdd35008e9ab32dffb7e401cdd7313b3461892">nested name specifiers</a> in the Clang AST. I have no idea what this is doing, but it improved Clang build time by <a href="https://llvm-compile-time-tracker.com/compare.php?from=fc44a4fcd3c54be927c15ddd9211aca1501633e7&to=91cdd35008e9ab32dffb7e401cdd7313b3461892&stat=instructions:u">~2.6%</a>, so this has a big impact on C++ heavy projects.</p> 139 140<p>Iâm especially happy about the Clang change, as Clang is our main source of unmitigated compile-time regressions.</p> 141 142<h2 id="optimizations">Optimizations</h2> 143 144<p>I donât tend to do much direct optimization work: If the optimization does not require significant IR or infrastru
144cture changes, we have plenty of other people who can work on it. But sometimes I canât resist, so here are a couple of the more interesting optimizations I worked on.</p> 145 146<p>Iâve implemented a <a href="https://github.com/llvm/llvm-project/pull/147540">store merge</a> optimization, which combines multiple stores into a single larger store. LLVM already had some support for this in the backend, but it was rather hit and miss. The reason I worked on this is that someone <a href="https://www.reddit.com/r/rust/comments/1lhgld6/why_do_these_bit_munging_functions_produce_bad_asm/">on Reddit</a> shared an example where Rustâs GCC backend actually produced better code than the LLVM backend, which is an injustice I just could not let stand.</p> 147 148<p>Iâve enabled the <a href="https://github.com/llvm/llvm-project/pull/153003">use of PredicateInfo</a><sup id="fnref:predicateinfo" role="doc-noteref"><a href="#fn:predicateinfo" class="footnote" rel="footnote">1</a></sup> in non-inter-procedural SCCP (sparse conditional constant propagation). This enables reliable optimization based on constant ranges implied by branches and assumptions. Previously we only handled this during inter-procedural SCCP, which runs very early, and CVP (correlated value propagation), which is based on LVI (lazy value info) and has problems dealing with loops<sup id="fnref:lvi_loops" role="doc-noteref"><a href="#fn:lvi_loops" class="footnote" rel="footnote">2</a></sup>. The main work here went into speeding up PredicateInfo, but we still had to eat a ~0.1% compile-time regression in the end.</p> 149 150<p>Finally, Iâve implemented a pass to <a href="https://github.com/llvm/llvm-project/pull/159403">drop assumes</a> that are unlikely to be useful anymore. This partially addresses a recurring problem where adding more assumes degrades optimization quality. This is just a starting point, we should likely be dropping assumes with various degrees of aggressiveness at multiple pipeline positions.</p> 151 152<h2 id="rust">Rust</h2> 153 154<p>As usual, Iâve updated Rust to use <a href="https://github.com/rust-lang/rust/pull/135763">LLVM 20</a> and then <a href="https://github.com/rust-lang/rust/pull/143684">LLVM 21</a>. Similar to all recent updates, this came with compile-time improvements (<a href="https://perf.rust-lang.org/compare.html?start=2162e9d4b18525e4eb542fed9985921276512d7c&end=ce36a966c79e109dabeef7a47fe68e5294c6d71e&stat=instructions:u">LLVM 20</a>, <a href="https://perf.rust-lang.org/compare.html?start=ec7c02612527d185c379900b613311bc1dcbf7dc&end=dc0bae1db725fbba8524f195f74f680995fd549e&stat=instructions:u">LLVM 21</a>).</p> 155 156<p>Both updates went relatively smoothly. LLVM 21 ran into a BOLT instrumentation miscompile that defied local reproduction, but luckily an update of the host toolchain fixed it.</p> 157 158<p>With these updates we were able to use a number of new LLVM features, some of which were added specifically for use by Rust.</p> 159 160<p>The most significant is the use of <a href="https://github.com/rust-lang/rust/pull/145259">read-only captures</a> for non-mutable references. This lets LLVM know that not only canât the function modify the memory, but it also canât be modified through captured pointers after the call. This further increases the reliability of memory optimizations in Rust relative to C++.</p> 161 162<p>Another is the use of the <a href="https://github.com/rust-lang/rust/pull/144086"><code class="language-plaintext highlighter-rouge">alloc-variant-zeroed</code></a> attribute, which enables optimization of <code class="language-plaintext highlighter-rouge">__rust_alloc</code> + memset zero to <code class="language-plaintext highlighter-rouge">__rust_alloc_zeroed</code>. This ended up running into some LTO issues that required follow-up changes to fix attribute emission for allocator definitions.</p> 163 164<p>Weâre also marking by value arguments as <a href="https://github.com/rust-lang/rust/pull/145093"><code class="language-plaintext highlighter-rouge">dead_on_return</code></a> now, and using <a href="https://github.com/rust-lang/rust/pull/137271">getelementptr nuw</a> for pointer arithmetic.</p> 165 166<h2 id="packaging">Packaging</h2> 167 168<p>The LLVM team at Red Hat has shared responsibility for packaging LLVM on Fedora, CentOS Stream, and RHEL. Most of the work happens as part of round-robin maintenance of daily<sup id="fnref:daily_snapshots" role="doc-noteref"><a href="#fn:daily_snapshots" class="footnote" rel="footnote">3</a></sup> <a href="https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapsh
168ots/">snapshot builds</a>. In theory, snapshot builds ensure that shipping a new major version is as simple as incrementing a version number. In practice, it never works out quite that easily.</p> 169 170<p>In the previous year, we had already started using a monolithic build for the core llvm packages. This year, the mlir, polly, bolt, libcxx and flang builds were also merged into the monolithic build, which means that we only build libclc separately now. Additionally, the builds now use PGO. These improvements were made by my colleague <a href="https://github.com/kwk">kwk</a>.</p> 171 172<p>One change that I worked on, and which ended up as a big failure, was to increase the consistency between our main llvm package, and the llvmNN compatibility packages we provide for older versions. The compatibility packages install LLVM inside a prefixed path like <code class="language-plaintext highlighter-rouge">/usr/lib64/llvmNN</code>, while the main package is installed to the usual system paths. The idea was that we should always install to the prefixed path, and symlink from the system path. That way, the main package could be used the same as a compatibility package, avoiding the need for adjustments when switching between them.</p> 173 174<p>The first issue this ran into is that RPM does not support replacing a directory with a symlink during upgrades. There are <a href="https://docs.fedoraproject.org/en-US/packaging-guidelines/Directory_Replacement/">documented workarounds</a> using pretrans scriptlets, but those donât fully work.<sup id="fnref:pretrans_scriptlets" role="doc-noteref"><a href="#fn:pretrans_scriptlets" class="footnote" rel="footnote">4</a></sup> In the end we had to symlink individual files instead of symlinking entire directories.</p> 175 176<p>The second issue only became apparent much later, after this change had already shipped: It was no longer possible to install the 32-bit and 64-bit packages of LLVM at the same time (known as the âmultilibâ configuration). While the prefixed path for both packages is different, they both install symlinks in the same system paths, and once again, RPM canât deal with that. RPM has special âfile colorâ support that lets 64-bit files win over 32-bit ones, but <em>of course</em> it only works for ELF files, not for symlinks.</p> 177 178<p>I explored lots of options for fixing this, but everything ended up running into one missing RPM feature or another. In the end, I ended up inverting the symlink direction (making the version-prefixed paths point to the system path). The lesson learned here is that if you use RPM, you should avoid symlinks like the plague.</p> 179 180<h3 id="llvm-area-team-and-project-council">LLVM area team and project council</h3> 181 182<p>This year, LLVM adopted a new <a href="https://github.com/llvm/llvm-www/blob/main/proposals/LP0004-project-governance.md">governance process</a>, which includes elected area teams. Together with <a href="https://github.com/fhahn">fhahn</a> and <a href="https://github.com/arsenm">arsenm</a>, I have been <a href="https://discourse.llvm.org/t/llvm-area-team-election-results/84601?u=nikic">elected</a> to the LLVM area team. The LLVM area team holds a <a href="https://discourse.llvm.org/t/llvm-area-team-meetings/85368?u=nikic">meeting</a> every two weeks to discuss pending RFCs. (The meetings are public, but usually itâs just us three.)</p> 183 184<p>Our approach has generally been hands-off. We have explicitly approved some RFCs where people expressed uncertainty, but usually our only involvement has been to provide additional comments on RFCs with insufficient engagement.</p> 185 186<p>Unlike some other areas, I believe we had very few controversial proposals/discussions. One of them is an extensive discussion on <a href="https://discourse.llvm.org/t/rfc-a-consistent-set-of-semantics-for-the-floating-point-minimum-and-maximum-operations/89006?u=nikic">floating-point min/max semantics</a>, which has only been resolved recently. The other one was on <a href="https://discourse.llvm.org/t/rfc-de-type-ification-of-llvm-ir-why/88257?u=nikic">delinearization challenges</a>, but that was more a generic complaint than a specific proposal.</p> 187 188<p>As chair of the LLVM area team, I also participate in the project council. This is kind of the opposite of the area team, in that nearly all topics that reach the project council are controversial â things like the AI policy, the mandatory pull request proposal, and the sframe upstreaming. While progress has been made, we havenât reached final resolutions on many of these topics yet. The <a href="https://llvm.org/docs/AIToolPolicy.html">AI policy</a> is now live though.</p> 189 190<h3 id="other">Other</h3> 191 192<p>Towards the end of the year, we formed the <a href="https://discourse.llvm.org/t/rfc-forming-a-working-group-on-formal-specification-for-llvm/89056?u=nikic">formal specification working group</a>, which aims to close long standing correctness gaps in LLVM, especially relating to the provenance model. Iâve participated in various early discussions for this group and wrote up a draft <a href="https://hackmd.io/@nikic/SJBt4mFCll">provenance model</a> for LLVM. The current focus of the group is the <a href="https://discourse.llvm.org/t/rfc-add-a-new-byte-type-to-llvm-ir/89522?u=nikic">byte type</a>.</p> 193 194<p>Iâve deprecated the <a href="https://github.com/llvm/llvm-project/pull/163979">global context</a> in the LLVM C API, a common footgun. Iâve changed the representation of alignment in <a href="https://github.com/llvm/llvm-project/pull/163802">masked memory intrinsics</a>. Iâve simplified the in-memory <a href="https://github.com/llvm/llvm-project/pull/137958">blockaddress representation</a> and proposed <a href="https://discourse.llvm.org/t/rfc-changing-the-indirectbr-blockaddress-representation/88677?u=nikic">more significant changes</a> for the future.</p> 195 196<p>Last but not least, I reviewed approximately 2500 pull requests last year. Unfortunately, this is nowhere near enough to keep up with my review queue.</p> 197 198<div class="footnotes" role="doc-endnotes"> 199 <ol> 200 <li id="fn:predicateinfo" role="doc-endnote"> 201 <p>PredicateInfo performs SSA-renaming based on branch conditions and assumes. This results in something akin to SSI (static single information) form, and allows standard sparse dataflow propagation to make use of them. <a href="#fnref:predicateinfo" class="reversefootnote" role="doc-backlink">↩</a></p> 202 </li> 203 <li id="fn:lvi_loops" role="doc-endnote"> 204 <p>LVI is a shared analysis between JumpThreading and CVP. Because JumpThreading performs pervasive control-flow changes, it cannot preserve the dominator tree. As such, LVI also canât use the dominator tree. This results in a purely recursive analysis, which conservatively aborts on cycles, even if there is a common dominating condition. <
204a href="#fnref:lvi_loops" class="reversefootnote" role="doc-backlink">↩</a></p> 205 </li> 206 <li id="fn:daily_snapshots" role="doc-endnote"> 207 <p>In practice, we produce successful builds across all architectures and operating systems much less often than daily. Something always breaks. <a href="#fnref:daily_snapshots" class="reversefootnote" role="doc-backlink">↩</a></p> 208 </li> 209 <li id="fn:pretrans_scriptlets" role="doc-endnote"> 210 <p>They solve the upgrade problem, but not the downgrade problem, so still fail rpmdeplint. And handling downgrades requires a change to <em>previous</em> versions of the package. <a href="#fnref:pretrans_scriptlets" class="reversefootnote" role="doc-backlink">↩</a></p> 211 </li> 212 </ol> 213</div> 214 215 216 </section> 217 <footer> 218 <section class="followupActions"> 219 If you liked this article, you may want to <a href="/">browse my other articles</a> or 220 follow me on <a href="https://twitter.com/nikita_ppv">Twitter</a> or 221 <a href="https://mastodon.social/@nikic">Mastodon</a>. 222 </section> 223
223<script src="https://giscus.app/client.js" 224 data-repo="nikic/nikic.github.com" 225 data-repo-id="MDEwOlJlcG9zaXRvcnkyNjIzMDE1" 226 data-category="Blog posts" 227 data-category-id="DIC_kwDOACgGJ84Cl2x4" 228 data-mapping="pathname" 229 data-strict="0" 230 data-reactions-enabled="1" 231 data-emit-metadata="0" 232 data-input-position="bottom" 233 data-theme="light" 234 data-lang="en" 235 data-loading="lazy" 236 crossorigin="anonymous" 237 async> 238 </script>
238 239 </footer> 240</section> 241 242 </section> 243
243<script src="/asset/anchor.js"></script>
243 244
244<script> 245 anchors.add('h2, h3'); 246 </script>
246 247 </body> 248</html>
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.