|
150
|
1 =====================================================
|
|
|
2 LLVM parallel-libs Subproject Charter
|
|
|
3 =====================================================
|
|
|
4
|
|
|
5 ----------------------------------------------
|
|
|
6 Description
|
|
|
7 ----------------------------------------------
|
|
|
8 The LLVM open source project will contain a subproject named `parallel-libs`
|
|
|
9 which will host the development of libraries which are aimed at enabling
|
|
|
10 parallelism in code and which are also closely tied to compiler technology.
|
|
|
11 Examples of libraries suitable for hosting within the `parallel-libs`
|
|
|
12 subproject are runtime libraries and parallel math libraries. The initial
|
|
|
13 candidates for inclusion in this subproject are **StreamExecutor** and
|
|
|
14 **libomptarget** which would live in the `streamexecutor` and `libomptarget`
|
|
|
15 subdirectories of `parallel-libs`, respectively.
|
|
|
16
|
|
|
17 The `parallel-libs` project will host a collection of libraries where each
|
|
|
18 library may be dependent on other libraries from the project or may be
|
|
|
19 completely independent of any other libraries in the project. The rationale for
|
|
|
20 hosting independent libraries within the same subproject is that all libraries
|
|
|
21 in the project are providing related functionality that lives at the
|
|
|
22 intersection of parallelism and compiler technology. It is expected that some
|
|
|
23 libraries which initially began as independent will develop dependencies over
|
|
|
24 time either between existing libraries or by extracting common code that can be
|
|
|
25 used by each. One of the purposes of this subproject is to provide a working
|
|
|
26 space where such refactoring and code sharing can take place.
|
|
|
27
|
|
|
28 Libraries in the `parallel-libs` subproject may also depend on the LLVM core
|
|
|
29 libraries. This will be useful for avoiding duplication of code within the LLVM
|
|
|
30 project for common utilities such as those found in the LLVM support library.
|
|
|
31
|
|
|
32
|
|
|
33 ----------------------------------------------
|
|
|
34 Requirements
|
|
|
35 ----------------------------------------------
|
|
|
36 Libraries included in the `parallel-libs` subproject must strive to achieve the
|
|
|
37 following requirements:
|
|
|
38
|
|
|
39 1. Adhere to the LLVM coding standards.
|
|
|
40 2. Use the LLVM build and test infrastructure.
|
|
|
41 3. Be released under LLVM's license.
|
|
|
42
|
|
|
43
|
|
|
44 Coding standards
|
|
|
45 ----------------
|
|
|
46 Libraries in `parallel-libs` will match the LLVM coding standards. For existing
|
|
|
47 projects being checked into the subproject as-is, an exception will be made
|
|
|
48 during the initial check-in, with the understanding that the code will be
|
|
|
49 promptly updated to follow the standards. Therefore, a three month grace period
|
|
|
50 will be allowed for new libraries to meet the LLVM coding standards.
|
|
|
51
|
|
|
52 Additional exceptions to strict adherence to the LLVM coding standards may be
|
|
|
53 allowed in certain other cases, but the reasons for such exceptions must be
|
|
|
54 discussed and documented on a case-by-case basis.
|
|
|
55
|
|
|
56
|
|
|
57 LLVM build and test infrastructure
|
|
|
58 ----------------------------------
|
|
|
59 Using the LLVM build and test infrastructure currently means using `cmake` for
|
|
|
60 building, `lit` for testing, and `buildbot` for automating build and testing.
|
|
|
61 This project will follow the main LLVM project conventions here and track them
|
|
|
62 as they evolve.
|
|
|
63
|
|
|
64 Each subproject library will be able to build separately without a single,
|
|
|
65 unified cmake file, but each subproject libraries will also be integrated into
|
|
|
66 the LLVM build so they can be built directly from the top level of the LLVM
|
|
|
67 cmake infrastructure.
|
|
|
68
|
|
|
69
|
|
|
70 LLVM license
|
|
|
71 ------------
|
|
|
72 For simplicity, the `parallel-libs` project will use the normal LLVM license.
|
|
|
73 While some runtime libraries use a dual license scheme in LLVM, we anticipate
|
|
|
74 the project removing the need for this eventually and in the interim follow the
|
|
|
75 simpler but still permissive license. Among other things, this makes it
|
|
|
76 straightforward for these libraries to re-use core LLVM libraries where
|
|
|
77 appropriate.
|
|
|
78
|
|
|
79
|
|
|
80 ----------------------------------------------
|
|
|
81 Mailing List and Bugs
|
|
|
82 ----------------------------------------------
|
|
|
83 Two mailing lists will be set up for the project:
|
|
|
84
|
|
|
85 1. parallel_libs-dev@lists.llvm.org for discussions among project developers, and
|
|
|
86 2. parallel_libs-commits@lists.llvm.org for patches and commits to the project.
|
|
|
87
|
|
|
88 Each subproject library will manage its own components in Bugzilla. So, for
|
|
|
89 example, there can be several Bugzilla components for different parts of
|
|
|
90 StreamExecutor, etc.
|
