Go to file
Alex Richardson 8c387cbea7 Add builtins for aligning and checking alignment of pointers and integers
This change introduces three new builtins (which work on both pointers
and integers) that can be used instead of common bitwise arithmetic:
__builtin_align_up(x, alignment), __builtin_align_down(x, alignment) and
__builtin_is_aligned(x, alignment).

I originally added these builtins to the CHERI fork of LLVM a few years ago
to handle the slightly different C semantics that we use for CHERI [1].
Until recently these builtins (or sequences of other builtins) were
required to generate correct code. I have since made changes to the default
C semantics so that they are no longer strictly necessary (but using them
does generate slightly more efficient code). However, based on our experience
using them in various projects over the past few years, I believe that adding
these builtins to clang would be useful.

These builtins have the following benefit over bit-manipulation and casts
via uintptr_t:

- The named builtins clearly convey the semantics of the operation. While
  checking alignment using __builtin_is_aligned(x, 16) versus
  ((x & 15) == 0) is probably not a huge win in readably, I personally find
  __builtin_align_up(x, N) a lot easier to read than (x+(N-1))&~(N-1).
- They preserve the type of the argument (including const qualifiers). When
  using casts via uintptr_t, it is easy to cast to the wrong type or strip
  qualifiers such as const.
- If the alignment argument is a constant value, clang can check that it is
  a power-of-two and within the range of the type. Since the semantics of
  these builtins is well defined compared to arbitrary bit-manipulation,
  it is possible to add a UBSAN checker that the run-time value is a valid
  power-of-two. I intend to add this as a follow-up to this change.
- The builtins avoids int-to-pointer casts both in C and LLVM IR.
  In the future (i.e. once most optimizations handle it), we could use the new
  llvm.ptrmask intrinsic to avoid the ptrtoint instruction that would normally
  be generated.
- They can be used to round up/down to the next aligned value for both
  integers and pointers without requiring two separate macros.
- In many projects the alignment operations are already wrapped in macros (e.g.
  roundup2 and rounddown2 in FreeBSD), so by replacing the macro implementation
  with a builtin call, we get improved diagnostics for many call-sites while
  only having to change a few lines.
- Finally, the builtins also emit assume_aligned metadata when used on pointers.
  This can improve code generation compared to the uintptr_t casts.

[1] In our CHERI compiler we have compilation mode where all pointers are
implemented as capabilities (essentially unforgeable 128-bit fat pointers).
In our original model, casts from uintptr_t (which is a 128-bit capability)
to an integer value returned the "offset" of the capability (i.e. the
difference between the virtual address and the base of the allocation).
This causes problems for cases such as checking the alignment: for example, the
expression `if ((uintptr_t)ptr & 63) == 0` is generally used to check if the
pointer is aligned to a multiple of 64 bytes. The problem with offsets is that
any pointer to the beginning of an allocation will have an offset of zero, so
this check always succeeds in that case (even if the address is not correctly
aligned). The same issues also exist when aligning up or down. Using the
alignment builtins ensures that the address is used instead of the offset. While
I have since changed the default C semantics to return the address instead of
the offset when casting, this offset compilation mode can still be used by
passing a command-line flag.

Reviewers: rsmith, aaron.ballman, theraven, fhahn, lebedev.ri, nlopes, aqjune
Reviewed By: aaron.ballman, lebedev.ri
Differential Revision: https://reviews.llvm.org/D71499
2020-01-09 21:48:29 +00:00
clang Add builtins for aligning and checking alignment of pointers and integers 2020-01-09 21:48:29 +00:00
clang-tools-extra [clangd] Handle DeducedTemplateSpecializationType in TargetFinder 2020-01-09 16:14:11 -05:00
compiler-rt [cfi][test] cross-dso/stats.cpp: don't assume the order of static constructors 2020-01-08 15:50:51 -08:00
debuginfo-tests [debuginfo] Update test to account for missing __debug_macinfo 2019-11-11 10:40:47 -08:00
libc [libc] Add a convenience CMake rule to add testsuites. 2020-01-07 23:04:52 -08:00
libclc libclc: Drop the old python based build system 2019-11-08 09:59:40 -05:00
libcxx [libc++] Explicitly enumerate std::string external instantiations. 2020-01-09 15:51:02 -05:00
libcxxabi [demangle] Copy back some NFC commits from LLVM 2020-01-09 10:27:24 -08:00
libunwind [libunwind] Fix evaluating DWARF operation DW_OP_pick 2019-12-18 12:22:21 -08:00
lld Re-apply "[ELF] Allow getErrPlace() to work before Out::bufferStart is set" 2020-01-09 20:26:31 +00:00
lldb [lldb/SWIG] Undo incorrect substitution 2020-01-09 09:55:39 -08:00
llgo IR: Support parsing numeric block ids, and emit them in textual output. 2019-03-22 18:27:13 +00:00
llvm Add gdb pretty printer for MutableArrayRef, remove ConstArrayRef. 2020-01-09 22:43:45 +01:00
mlir [mlir] NFC: Move the state for managing SSA value names out of OperationPrinter and into a new class SSANameState. 2020-01-09 12:48:35 -08:00
openmp [OpenMP] NFC: Fix trivial typos in comments 2020-01-07 14:05:03 +08:00
parallel-libs Fix typos throughout the license files that somehow I and my reviewers 2019-01-21 09:52:34 +00:00
polly [cmake] Use source-groups in Polly. 2020-01-07 14:20:06 -06:00
pstl [pstl] Allow customizing whether per-TU insulation is provided 2019-08-13 12:49:00 +00:00
.arcconfig Update monorepo .arcconfig with new project callsign. 2019-01-31 14:34:59 +00:00
.clang-format Add .clang-tidy and .clang-format files to the toplevel of the 2019-01-29 16:43:16 +00:00
.clang-tidy Disable tidy checks with too many hits 2019-02-01 11:20:13 +00:00
.git-blame-ignore-revs Add LLDB reformatting to .git-blame-ignore-revs 2019-09-04 09:31:55 +00:00
.gitignore Add a newline at the end of the file 2019-09-04 06:33:46 +00:00
CONTRIBUTING.md Add contributing info to CONTRIBUTING.md and README.md 2019-12-02 15:47:15 +00:00
README.md Add contributing info to CONTRIBUTING.md and README.md 2019-12-02 15:47:15 +00:00

README.md

The LLVM Compiler Infrastructure

This directory and its subdirectories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and runtime environments.

The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting Started with the LLVM System

Taken from https://llvm.org/docs/GettingStarted.html.

Overview

Welcome to the LLVM project!

The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and converts it into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.

C-like languages use the Clang front end. This component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.

This is an example workflow and configuration to get and build the LLVM source:

  1. Checkout LLVM (including related subprojects like Clang):

    • git clone https://github.com/llvm/llvm-project.git

    • Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git

  2. Configure and build LLVM and Clang:

    • cd llvm-project

    • mkdir build

    • cd build

    • cmake -G <generator> [options] ../llvm

      Some common generators are:

      • Ninja --- for generating Ninja build files. Most llvm developers use Ninja.
      • Unix Makefiles --- for generating make-compatible parallel makefiles.
      • Visual Studio --- for generating Visual Studio projects and solutions.
      • Xcode --- for generating Xcode projects.

      Some Common options:

      • -DLLVM_ENABLE_PROJECTS='...' --- semicolon-separated list of the LLVM subprojects you'd like to additionally build. Can include any of: clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, or debuginfo-tests.

        For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi".

      • -DCMAKE_INSTALL_PREFIX=directory --- Specify for directory the full pathname of where you want the LLVM tools and libraries to be installed (default /usr/local).

      • -DCMAKE_BUILD_TYPE=type --- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.

      • -DLLVM_ENABLE_ASSERTIONS=On --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).

    • Run your build tool of choice!

      • The default target (i.e. ninja or make) will build all of LLVM.

      • The check-all target (i.e. ninja check-all) will run the regression tests to ensure everything is in working order.

      • CMake will generate build targets for each tool and library, and most LLVM sub-projects generate their own check-<project> target.

      • Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make, use make -j NNN (NNN is the number of parallel jobs, use e.g. number of CPUs you have.)

    • For more information see CMake

Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.