maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
371,431 Commits 23 Branches 0 Tags 2.2 GiB
C++ 39.1%
LLVM 35.7%
C 12.1%
Assembly 8.9%
Python 1.1%
Other 2.7%
Go to file
Renato Golin 25ba6b2bcd [docs] Adding a Support Policy 
As discussed in the mailing list [1-4], we need a separation of support
tiers when requiring support from the whole community versus a
sub-community. Essentially, if a sub-community is active enough and
takes maintenance into their own internal costs without affecting other
parts of the community's maintenance costs, then code that is not
immediately relevant to all parts (ie. not released, actively tested,
etc) can still find its way into the LLVM main repository without major
pain points.

The main benefit is to reduce the maintenance cost that those
sub-communities have outside of LLVM (for example, in duplicating common
code, applying the same patches on top of multiple user repositories or
downstream projects).

This document outlines the components and responsibilities of the
sub-communities with regards to maintenance costs and how they affect
the rest of the community.

It also adds an addendum on removal policies, which expand the existing
"new target removal" policy into something more generic, to encompass
any piece of code, scripts or documents in the repository.

[1] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146249.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146335.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2020-October/146138.html
[4] http://lists.llvm.org/pipermail/llvm-dev/2020-November/146298.html
 		2020-11-07 21:06:05 +00:00
clang [clang] Fix length threshold for MicrosoftMangle md5 hash 2020-11-07 07:40:24 -08:00
clang-tools-extra [clang-tidy] Use vfs::FileSystem when getting config 2020-11-07 19:18:02 +00:00
compiler-rt [scudo][standalone] Simplify populateFreelist 2020-11-06 09:44:36 -08:00
debuginfo-tests [debuginfo-tests] Skip optnone-loops.cpp on Darwin 2020-11-06 13:05:33 -08:00
flang [flang][openacc] Add parsing tests and semantic check for set directive 2020-11-05 22:57:58 -05:00
libc [libc] Extend WrapperGen to emit aliases. 2020-11-06 16:12:10 -08:00
libclc libclc: Use find_package to find Python 3 and require it 2020-10-01 22:31:33 +02:00
libcxx Revert "Allow running back-deployment testing against libc++abi" 2020-11-06 17:26:42 -05:00
libcxxabi Revert "Allow running back-deployment testing against libc++abi" 2020-11-06 17:26:42 -05:00
libunwind Revert "Allow running back-deployment testing against libc++abi" 2020-11-06 17:26:42 -05:00
lld [lld testing] Unbreak read-only source builds 2020-11-06 07:13:55 -05:00
lldb [lldb] [test] Use skipUnlessDarwin for tests specific to Darwin 2020-11-07 19:26:42 +01:00
llvm [docs] Adding a Support Policy 2020-11-07 21:06:05 +00:00
mlir Add missing dependency to TOSA library: fix build with -DBUILD_SHARED_LIBS=ON 2020-11-07 18:58:18 +00:00
openmp [libomptarget] Add support for target update non-contiguous 2020-11-06 20:55:33 -06:00
parallel-libs Reapply "Try enabling -Wsuggest-override again, using add_compile_options instead of add_compile_definitions for disabling it in unittests/ directories." 2020-07-22 17:50:19 -07:00
polly [polly] Fix -Wunused-lambda-capture and -Wunused-variable 2020-11-02 20:35:26 -08:00
pstl [pstl] Replace direct use of assert() with _PSTL_ASSERT 2020-11-02 18:35:54 -05:00
utils/arcanist Fix arc lint's clang-format rule: only format the file we were asked to format. 2020-10-11 14:24:23 -07:00
.arcconfig [arcconfig] Default base to previous revision 2020-02-24 16:20:25 -08:00
.arclint PR46997: don't run clang-format on clang's testcases. 2020-08-04 17:53:25 -07:00
.clang-format
…
.clang-tidy - Update .clang-tidy to ignore parameters of main like functions for naming violations in clang and llvm directory 2020-01-31 16:49:45 +00:00
.git-blame-ignore-revs NFC: Add whitespace-changing revisions to .git-blame-ignore-revs 2020-09-21 20:17:24 -04:00
.gitignore [NFC] Adding pythonenv* to .gitignore 2020-09-03 22:42:27 -04:00
CONTRIBUTING.md
…
README.md Revert "This is a test commit" 2020-10-21 09:34:15 +08:00

README.md

The LLVM Compiler Infrastructure

This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time 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 work-flow and configuration to get and build the LLVM source:

  1. Checkout LLVM (including related sub-projects 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 build system 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 sub-projects 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 path name 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).

    • cmake --build . [-- [options] <target>] or your build system specified above directly.

      • 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 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 the option -j NNN, where NNN is the number of parallel jobs, e.g. the 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.