LLVM Weekly - #584, March 10th 2025

[asb]

LLVM Weekly - #584, March 10th 2025

If you prefer, you can read the canonical version of this issue at https://llvmweekly.org/issue/584.

Welcome to the five hundred and eighty-fourth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by Alex Bradbury. Subscribe to future issues at https://llvmweekly.org and pass it on to anyone else you think may be interested. Please send any tips or feedback via email: [email protected], or Mastodon: @[email protected] / @[email protected], or Bluesky: @llvmweekly.org / @asbradbury.org.

News and articles from around the web and events

The program for the 2025 EuroLLVM program has been announced and early bird registration ends on March 12th.

The call for proposals for 2025 AsiaLLVM is open through to March 31st. The event will take place on June 10th in Tokyo. There’s also an open call for program committee and student travel grant review committee members.

Fangrui Song blogged about compiling C++ with the Clang API.

As warned last time, the US entered daylight savings time over the weekend but much of the rest of the work isn’t in daylight savings yet. So expect some confusion about times or altered meeting slots. According to the LLVM calendar in the coming week there will be the following:

• Office hours with the following hosts: Alexey Bader, Aaron Ballman, Alina Sbirlea, Kristof Beyls, Johannes Doerfert, MLIR area team.
• Online sync-ups on the following topics: pointer authentication, alias analysis, OpenMP, Flang, BOLT, LLVM libc, RISC-V, canonical wrapping and non-wrapping types.
• For more details see the LLVM calendar, getting involved documentation on online sync ups and office hours.

On the forums

• LLVM 20.1.0 has been tagged.

• On behalf of the Clang Area Team, Aaron Ballman summarised their plans for meeting and for handling RFCs. To highlight one aspect “The RFC process is not being drastically changed. Authors will continue to write their proposals on Discourse (please remember to add [RFC] to the post title) and proposals which have obvious consensus (for or against) will not need to be seen by the area team. However, the Clang Area Team secretary will proactively look for RFCs that appear to not have a clear path forward to add them to the team’s agenda.”

• Matthias Springer highlighted that match and rewrite are now deprecated in MLIR in favour of matchAndRewrite.

• Serge Pavlov proposes changes to strict floating point operation representation in IR.

• In a discussion on plans for NewGVN, Nikia Popov queried if it should be deleted at this point with effort redirected to improving the current GVN (global value numbering) implementation.

• Nikhil Kalra raised the issue of MLIR bytecode dialect versioning and fallback mechanisms, coming from the perspective of having to support a scenario where bytecode is used as an exchange format and reader of the bytecode may not support the version being sent.

• Yusuke Minato authored a flang RFC on improving the performance of Fortran::runtime::Assign for derived types.

• Michael Adams shared version 0.3.0 of lecture slides for using Clang libraries.

• Sylvestre Ledru and Serge Guelton propose moving llvm-toolchain-integration-test-suite under the LLVM umbrella.

• If you’re interested in submitting a proposal for LLVM in Google summer of Code this year, but sure to read Anton Korobeynikov’s pinned post on GSoC.

• Andrzej Warzynski started a thread to discuss the process for code review when upstreaming patches that might have co-authorship.

• There’s a thread discussing Clang’s ability to accept MISRA check tools, featuring input from the Andrew Banks, Chairman of the MISRA C Working Group. As Aaron Ballman summarises, there doesn’t seem to be a clear path forwards with the current restrictions, but Andrew has offered to discuss these issues at MISRA.

• Paul Kirth posted an RFC on addressing deficiencies in LLVM’s LTO implementation.

LLVM commits

• The Module data structure now stores a Triple rather than just storing the target triple as a string. 979c275.

• Support was added for the RISC-V VLS calling convention. c804e86.

• MachineSink, RemoveRedundantDebugValue, FixupStatePointCallerSaved, and ExpandPostRAPseudos was ported to the new pass manager. 77f44a96, 6abe148, e0eb4ed.

• A CI best practices document was started, which currently contains guidance for work on LLVM’s GitHub Actions. 829401f.

• A pass was added to the SPIR-V backend to remove spv_ptrcast intrinsics. 7c8b127.

• The SLPVectorizer spill cost analysis was improved. 855178a.

• Code generation was implemented for the Qualcomm Xqccmp vendor RISC-V extension and assembler support was added for Qualcomm’s Xqcibm (bit manipulation) extension. e49180d, 6e7e46c.

• Support was added for the SPIR-V SPV_INTEL_memory_access_aliasing extension. 7a44ff1.

• A RISCVLoadStoreOptimizer pass was implemented in order to produce load/store pairs for the relevant MIPS RISC-V vendor extension. 5048a08.

Clang commits

• An alpha.core.FixedAddressDereference checker was added. da7403e.

• AST components and semantic analysis for OpenACC’s declare, cache, and routine constructs was implemented. 5d7d66b, d5cec38, df1e102.

• ClangIR lowering can now produce Func, Return, Alloca, Load, and Store ops. fa072bd.

• Clang’s diagnostics were improved by more consistently pointing to the relevant template parameter. a24523a.

Other project commits

• ranges::swap_ranges was optimised for vector<bool>::iterator yielding up to 611x performance improvements. a12744f.

• LLD’s WebAssembly linker now supports the custom-page-sizes WebAssembly proposal. 6018930.

• libclc headers will no longer be installed. They are intended as an internal implementation detail. a2b0576.

• LLDB no longer supports coalescing progress reports as the main user (XCode) is moving to the regular full progress events. a1b14db.

• MLIR’s match and rewrite functions were deprecated. matchAndRewrite should be used instead. a21cfca320.