LLVM Weekly - #447, July 25th 2022

Welcome to the four hundred and forty-seventh 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 http://llvmweekly.org and pass it on to anyone else you think may be interested. Please send any tips or feedback to asb@asbradbury.org, or @llvmweekly or @asbradbury on Twitter.

News and articles from around the web

The next LLVM Bay Area meetup will take place on Mon August 8th.

Carbon, an “experimental successor to C++” (using LLVM of course) was announced in a CppNorth keynote.

JeanHeyd Meneide blogged about what went in to getting #embed into C23.

On the forums

• On behalf of the LLVM Foundation Board of Directors, Tom Stellard announced the decision to migrate to GitHub Pull Requests for code review. The planning transition date is not until October 1, 2023. “Despite the challenges, we need to get off of Phabricator, and the “must have” developer workflows are already supported by GitHub. We don’t feel that the remaining deficiencies with GitHub Pull Requests overcome benefits of moving to Pull Requests have - but we do think it is important to try to improve the workflows and know it is important to give time for auxiliary workflows to adapt. To do this, we set the target transition date to October 1, 2023. Allowing over a year should provide enough time to adapt, and time to find workarounds/solutions for at least some of the deficiencies that remain.” A large number of responses were generated, discussing the pros/cons of the move and the feasibility of other options.

• Amara Emerson proposed enabling GlobalISel for all optimisation levels for Apple AArch64 platforms. Although there are still fallbacks from GlobalISel to SelectionDAG, this would be a major milestone for the GlobalISel infrastructure. Amara reports that Apple benchmarks show generated code performance within about 1% of the SelectionDAG geomean.

• The LLVM 15 release branch is due to be created imminently, on Tue the 26th.

• Wren Romano posted an RFC on adding direct support for permutations in MLIR.

• “Whisperity” proposed adding the ability to enhance clang-tidy with project-level knowledge. The proposal involves adding a map-reduce-like infrastructure for checks consisting of “collect” (map), “compact” (reduce", and “diagnose” phases. See the (very detailed) RFC for more information.

• Arda Unal suggested introducing -ffat-lto-objects support, similar to GCC’s support for allowing GIMPLE bytecode to be saved alongside object code using the same object name. Some respondents query the necessity of such support, and how it relates to other ongoing LTO work.

• Krishna Chaitanya Sankisa proposed introducing a maybe_undef attribute for function arguments to better support languages like CUDA, HIP that accept uninitialised function arguments.

• Slava Zakharin is seeking feedback on changes to lowering of Fortran math intrinsics.

• Matthew Voss shared CTMark results for the ThinLTO pipeline vs the proposed unified LTO pipeline.

• River Riddle shared information about recent enhancements to the MLIR language server.

• Discussion about the proposed addition of an MLIR interpreter framework continued, with Mehdi Amini raising concerns about the level of push-back received, and Stella Laurenzo and Chris Lattner offering responses.

• LLVM GPU News #38 is out.

LLVM commits

• llvm-dwarfutil was introduced, providing a dsymutil-like tool for ELF. 4539b44.

• Basic support for MemProf metadata (as described in the previous RFC) was committed. 0174f55, 1dad624.

• zstd was added to the llvm::compression namespace. e939bf6.

• AAPotentialValues was introduced and used to replace AAValueSimplify. bf789b1.

• The unmaintained table of features supported by each target was removed from the documentation. 86c4242.

• CCAssignToRegAndStack was introduced to help define calling convention that assign a value to a regsiter and allocate a stack slot. SystemZ was converted to use this rather than calling into C++ code to implement the logic. 6fb27bc.

• The x86 backend now generates a zero-extending byte load when possible except when compiling with -Os/-Oz. f0dd12e.

• Various minor codegen optimisations were made for RISC-V. 7c0b9b3, d7f2a63, 0b02752, 31b8939.

• update_test_checks was enhanced to handle tests with #if. 5a4033c.

• The preferPredicateOverEpilogue target hook was implemented for AArch64 and returns true when SVE is enabled. f15b6b2.

• The SPIRVPrepareFunctions pass was introduced. It will modify function signatures containing aggregate arguments and/or return values before IR translation. b8e1544.

• A note on opaque pointers was added to the release notes and the status updated in the LangRef. 5102084, 5ab077f.

• Support for the RISC-V Zmmul extension was added. 3198364.

Clang commits

• -Wint-conversion now defaults to an error in C, as it does in C++. 7068aa9.

• -fstrict-flex-arrays=<n> was introduced for stricter handling of flexible arrays. f764dc99.

• The clang:SarifDocumentWriter interface was introduced, as a step towards adding support for writing SARIF documents. 4b03ad6.

• -fexperimental-library was introduced to enable experimental library features. ca495e3.

• The clang pseudo parser can now dump a HTML+JS representation of its parse forest. This is intended to aid debugging. c91ce94.

Other project commits

• Unicode grapheme clustering was implemented in libcxx. 857a78c.

• ThreadSanitizer’s DenseSlabAlloc was optimised to reduce overhead from multi-thread contention. 6d1f860.

• LLVM’s libc gained a sinf function that is correctly rounded to all rounding modes. d883a4a.

• libomptaget.so now depends on LLVM libraries, linking against LLVMSupport and LLVMObject. dc52712.