LLVM 10.0.0 to be Released

New version of the popular development toolkit brings, among other things, support for the C++ Concepts
26 March 2020   949

After six months of development, the release of the LLVM 10.0 project, a GCC-compatible toolkit (compilers, optimizers, and code generators), compiling programs into an intermediate bitcode of RISC-like virtual instructions (a low-level virtual machine with a multi-level optimization system), is presented. The generated pseudo-code can be converted using the JIT compiler into machine instructions directly at the time of program execution.

Among the new features of LLVM 10.0, there are support for C ++ Concepts (C ++ Concepts), termination of the launch of Clang in the form of a separate process, support for CFG checks (control flow guard) for Windows, and support for new CPU features.

The main innovations of LLVM 10.0:

  • New interprocedural optimizations and analyzers have been added to the Attributor framework. The prediction of the state of 19 different attributes, including 12 attributes of 12 LLVM IR and 7 abstract attributes such as liveness, is provided.
  • New built-in compiler matrix mathematical functions (Intrinsics) have been added, which, when compiled, are replaced by effective vector instructions.
  • Numerous improvements to the backends for the X86, AArch64, ARM, SystemZ, MIPS, AMDGPU, and PowerPC architectures. Added support for Cortex-A65, Cortex-A65AE, Neoverse E1 and Neoverse N1 CPUs. For ARMv8.1-M, ​​the code generation process has been optimized (for example, support for loops with minimal overhead has appeared) and support for auto-vectorization using the MVE extension has been added. Improved support for CPU MIPS Octeon. PowerPC includes vectorization of mathematical routines using the MASSV (Mathematical Acceleration SubSystem) library, improved code generation, and optimized memory access from loops. For x86, the processing of vector types v2i32, v4i16, v2i16, v8i8, v4i8 and v2i8 has been changed.
  • Improved code generator for WebAssembly. Added support for TLS (Thread-Local Storage) and atomic.fence instructions. Significantly expanded support for SIMD. WebAssembly object files added the ability to use function signatures with multiple values.
  • When processing cycles, the MemorySSA analyzer is used to determine the dependencies between different memory operations. MemorySSA can reduce compilation and execution time, or can be used instead of AliasSetTracker without sacrificing performance.
  • The LLDB debugger has significantly improved support for the DWARF v5 format. Improved build support with MinGW and added the initial ability to debug Windows executable files for ARM and ARM64 architectures. Added descriptions of options offered when autocompleting input by pressing tabs.
  • Enhanced LLD Linker Features. Improved support for the ELF format, including full compatibility of glob templates with the GNU linker, added support for the compressed debug sections ".zdebug", added the PT_GNU_PROPERTY property to determine the .note.gnu.property section (can be used in future Linux kernels), implemented modes "-z noseparate-code", "-z separate-code" and "-z separate-loadable-segments". Improved support for MinGW and WebAssembly.

Get more at the release notes.

CMake 3.17.0 to be Released

The new version of the popular software assembly automation system brings a lot changes and updates
23 March 2020   348

The release of the cross-platform open source script generator CMake 3.17, acting as an alternative to Autotools and used in projects such as KDE, LLVM / Clang, MySQL, MariaDB, ReactOS and Blender, is presented. The CMake code is written in C ++ and is distributed under the BSD license.

These are the key changes and updates:

  • “cmake(1)” gained a “Ninja Multi-Config” generator, which is similar to the “Ninja” generator but can be used to build multiple configurations at once.
  • Visual Studio Generators learned to support per-config sources. Previously only Command-Line Build Tool Generators supported them.
  • The “Compile Features” functionality now offers meta-features for the CUDA language standard levels (e.g. “cuda_std_03”, “cuda_std_14”). See “CMAKE_CUDA_KNOWN_FEATURES”.
  • The “CMAKE_CUDA_RUNTIME_LIBRARY” variable and “CUDA_RUNTIME_LIBRARY” target property were introduced to select the CUDA runtime library used when linking targets that use CUDA.
  • The “FindCUDAToolkit” module was added to find the CUDA Toolkit without enabling CUDA as a language.
  • “cmake(1)” gained a “–debug-find” command-line option to enable additional human-readable output on where find commands search.
  • The “CMAKE_FIND_DEBUG_MODE” variable was introduced to print extra find call information during the cmake run to standard error. Output is designed for human consumption and not for parsing.
  • The “FindCURL” module learned to find CURL using the “CURLConfig.cmake” package configuration file generated by CURL’s cmake buildsystem. It also gained a new “CURL_NO_CURL_CMAKE” option to disable this behavior.
  • The “FindPython” module has learned to find Python components in active virtual environments managed by “conda”.
  • The “ctest(1)” tool gained a “–no-tests=<[error|ignore]>” option to explicitly set and unify the behavior between direct invocation and script mode if no tests were found.
  • The “ctest(1)” tool gained a “–repeat :” option to specify conditions in which to repeat tests. This generalizes the existing “–repeat-until-fail ” option to add modes for “until-pass” and “after-timeout”.
  • Target link properties “INTERFACE_LINK_OPTIONS”, “INTERFACE_LINK_DIRECTORIES” and “INTERFACE_LINK_DEPENDS” are now transitive over private dependencies on static libraries. See policy “CMP0099”.
  • When using MinGW tools, the “find_library()” command no longer finds “.dll” files by default. Instead it expects “.dll.a” import libraries to be available.
  • The “Ninja” generator now prefers the first ninja build tool to appear in the “PATH” no matter whether it is called “ninja-build”, “ninja”, or “samu”. Previously the first of those names to appear anywhere in the “PATH” would be preferred.
  • “cmake(1)” gained a “-E rm” command-line tool that can be used to remove directories and files. This supersedes the existing “-E remove” and “-E remove_directory” tools and has better semantics.

Get more at the Kitware blog.