Update GettingStarted guide to recommend that people use the new official Git repository.

[jyknight]

Summary

Remove the directions for using git-svn, and demote the prominence of
the svn instructions.

Also, fix a few other issues while I'm in there:

• Mention LLVM_ENABLE_PROJECTS more.
• Getting started doesn't need to mention test-suite, but should mention clang and the other projects.
• Remove mentions of "configure", since that's long gone.

I've also adjusted a few other mentions of svn to point to github, but
have not done so comprehensively.

[smeenai]

llvm/docs/DeveloperPolicy.rst

85

checkout from git? Or maybe clone.

llvm/docs/GettingStarted.rst

65

Do you think LLVM_ENABLE_RUNTIMES is worth mentioning as well, or would that be information overload for a getting started guide?

Also, typo: semicolor -> semicolon

434

so you'll

[jlebar]

Well this is heroic.

llvm/docs/GettingStarted.rst

24

Nit: "There's" stands for "There is", which doesn't fit. :)

26

Comma after libc++?

41

Maybe we could be explicit that this checks out "greater LLVM" rather than "lesser LLVM", especially since this is different from how it used to be.

96

or just make -j?

438

"points upstream" (or I suppose "points to the upstream repository")

438

points to your

439

s#is rebased onto#is based on origin/master without merges#? Like, rebasing is an action, and the result of the action is...that one branch is based on another without merges (or something).

444

I wonder if now would be a good point to mention clang-format (and the git-clang-format script) instead? Like, overall that's probably more useful to introduce to beginners than git diff --check.

582

Instead of or in addition to listing them, would it be worthwhile to explain where the canonical list of allowed strings lives (or how to print it)? That way the list never goes out of date.

llvm/docs/Phabricator.rst

200

I would think that you don't want to merge the change into your local "master" branch, because you probably (?) want that to be a copy of origin/master, and upstream is going to rewrite this change. IOW git checkout master; git pull --ff-only origin/master will fail.

Would it make more sense to checkout arcpatch-D123, merge origin/master into it, and then git llvm push from that branch?

(I'm also confused why we're talking about patching in a change from phab -- isn't the most likely scenario that you already have the change in your git repository?)

[mehdi_amini]

llvm/docs/GettingStarted.rst

96

make -j is "unbounded" parallelism, it use to hang my machine for a while last time I tried it on clang.

450

These instructions assume that "my branch" is perfectly rebased, I think this should use three dots to do what we want: git diff origin/master...mybranch

llvm/docs/Phabricator.rst

200

Would it make more sense to checkout arcpatch-D123, merge origin/master into it, and then git llvm push from that branch?

My usual flow would be to rebase: git checkout arcpatch-D123 && git fetch && git rebase origin/master

[jyknight]

Address various comments.

[jyknight]

llvm/docs/GettingStarted.rst

65

I don't actually know what that does and when one would want to use it. So either I've been missing out terribly, or else it's not needed for a getting started guide. :)

96

"make -j" is bad, it doesn't run number-of-CPUs jobs, instead it puts NO limit on the number of jobs. That usually, IME, eats up all your RAM and destroys your computer.

444

Seems reasonable.

450

Now that I look over this again, I don't think most of this belongs in here, at all. I rewrote this part to just point people to the Phab instructions, and just left a note that email is also OK.

582

I have no idea how to print a list from cmake. Is that even possible? I don't think pointing to the source code would be very helpful, I'd prefer to just have an outdated list vs that.

llvm/docs/Phabricator.rst

200

I've adjusted these instructions.

[smeenai]

llvm/docs/GettingStarted.rst

65

It automatically sets up a two-stage build where the selected runtimes (it supports all of libc++, libunwind, compiler-rt, etc.) are built using the just-built clang instead of the host compiler. That's supposedly The Right Thing™ to do for building the runtimes, which is why I was thinking about promoting it, but it's probably not needed here.

[jlebar]

llvm/docs/GettingStarted.rst

582

I have no idea how to print a list from cmake. Is that even possible?

Heh, no idea either. /me summons @tra, he has suffered through more than his fair share of cmake.

[smeenai]

llvm/docs/GettingStarted.rst

65

The typo is still there, I think ... semicolor -> semicolon

[jyknight]

Thanks all! Going ahead and committing this now; if there's further changes requested, I'll do followup commits.

llvm/docs/GettingStarted.rst

65

Oops, missed that half of the comment, now fixed.

[tra]

llvm/docs/GettingStarted.rst

582

AFAICT, there's no explicitly defined canonical list of projects. Judging by the llvm/CMakeLists.txt it appears that a project must be a top-level repo directory :
https://github.com/llvm-mirror/llvm/blob/master/CMakeLists.txt#L113

I'm not sure if all top level directories are projects, though.

llvm/docs/DeveloperPolicy.rst

 LLDB, libc++, etc.
 
 This policy is also designed to accomplish the following objectives:
 
 #. Attract both users and developers to the LLVM project.
 
 #. Make life as simple and easy for contributors as possible.
 
-#. Keep the top of Subversion trees as stable as possible.
+#. Keep the tip of tree as stable as possible.
 
 #. Establish awareness of the project's :ref:`copyright, license, and patent
    policies <copyright-license-patents>` with contributors to the project.
 
 This policy is aimed at frequent contributors to LLVM. People interested in
 contributing one-off patches can do so in an informal way by sending them to the
 `llvm-commits mailing list
 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_ and engaging another

 .. _one-off patches:
 
 Making and Submitting a Patch
 -----------------------------
 
 When making a patch for review, the goal is to make it as easy for the reviewer
 to read it as possible.  As such, we recommend that you:
 
-#. Make your patch against the Subversion trunk, not a branch, and not an old
-   version of LLVM.  This makes it easy to apply the patch.  For information on
-   how to check out SVN trunk, please see the `Getting Started
-   Guide <GettingStarted.html#checkout>`_.
+#. Make your patch against git master, not a branch, and not an old version
+   of LLVM.  This makes it easy to apply the patch.  For information on how to
+   check from git, please see the `Getting Started Guide
+   <GettingStarted.html#checkout>`_.
 
 #. Similarly, patches should be submitted soon after they are generated.  Old
    patches may not apply correctly if the underlying code changes between the
    time the patch was created and the time it is applied.
 
-#. Patches should be made with ``svn diff``, or similar. If you use a
+#. Patches should be made with ``git format-patch``, or similar. If you use a
    different tool, make sure it uses the ``diff -u`` format and that it
    doesn't contain clutter which makes it hard to read.
 
-#. If you are modifying generated files, such as the top-level ``configure``
-   script, please separate out those changes into a separate patch from the rest
-   of your changes.
-
 Once your patch is ready, submit it by emailing it to the appropriate project's
 commit mailing list (or commit it directly if applicable). Alternatively, some
 patches get sent to the project's development list or component of the LLVM bug
 tracker, but the commit list is the primary place for reviews and should
 generally be preferred.
 
 When sending a patch to a mailing list, it is a good idea to send it as an
 *attachment* to the message, not embedded into the text of the message.  This

 review when they are confident they are right.
 
 The trick to this is that the project has to guarantee that all patches that are
 committed are reviewed after they go in: you don't want everyone to assume
 someone else will review it, allowing the patch to go unreviewed.  To solve this
 problem, we have a notion of an 'owner' for a piece of the code.  The sole
 responsibility of a code owner is to ensure that a commit to their area of the
 code is appropriately reviewed, either by themself or by someone else.  The list
-of current code owners can be found in the file
-`CODE_OWNERS.TXT <http://git.llvm.org/klaus/llvm/blob/master/CODE_OWNERS.TXT>`_
-in the root of the LLVM source tree.
+of current code owners can be found in the file `CODE_OWNERS.TXT
+<https://github.com/llvm/llvm-project/blob/master/llvm/CODE_OWNERS.TXT>`_ in the
+root of the LLVM source tree.
 
 Note that code ownership is completely different than reviewers: anyone can
 review a piece of code, and we welcome code review from anyone who is
 interested.  Code owners are the "last line of defense" to guarantee that all
 patches that are committed are actually reviewed.
 
 Being a code owner is a somewhat unglamorous position, but it is incredibly
 important for the ongoing success of the project.  Because people get busy,

llvm/docs/GettingStarted.rst

 ====================================
 Getting Started with the LLVM System
 ====================================
 
 .. contents::
    :local:
 
 Overview
 ========
 
-Welcome to LLVM! In order to get started, you first need to know some basic
-information.
+Welcome to the LLVM project! In order to get started, you first need to know
+some basic information.
 
-First, LLVM comes in three pieces. The first piece is the LLVM suite. This
-contains all of the tools, libraries, and header files needed to use LLVM.  It
-contains an assembler, disassembler, bitcode analyzer and bitcode optimizer.  It
-also contains basic regression tests that can be used to test the LLVM tools and
-the Clang front end.
-
-The second piece is the `Clang <http://clang.llvm.org/>`_ front end.  This
-component compiles C, C++, Objective C, and Objective C++ code into LLVM
-bitcode. Once compiled into LLVM bitcode, a program can be manipulated with the
-LLVM tools from the LLVM suite.
-
-There is a third, optional piece called Test Suite.  It is a suite of programs
-with a testing harness that can be used to further test LLVM's functionality
-and performance.
+First, 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 an intermediate representation and convert it into
+object files.  It contains an assembler, disassembler, bitcode analyzer and
+bitcode optimizer.  It also contains basic regression tests.
+
+Another piece is the `Clang <http://clang.llvm.org/>`_ front end.  This
+component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode
+-- and from there into object files, using LLVM.
+
+There's other components as well:
+the `libc++ C++ standard library <https://libcxx.llvm.org>`
+the `LLD linker <https://lld.llvm.org>`, and more.
 
 Getting Started Quickly (A Summary)
 ===================================
 
 The LLVM Getting Started documentation may be out of date.  So, the `Clang
 Getting Started <http://clang.llvm.org/get_started.html>`_ page might also be a
 good place to start.
 
 Here's the short story for getting up and running quickly with LLVM:
 
 #. Read the documentation.
 #. Read the documentation.
 #. Remember that you were warned twice about reading the documentation.
 
-   * In particular, the *relative paths specified are important*.
-
 #. Checkout LLVM:
 
-   * ``cd where-you-want-llvm-to-live``
-   * ``svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm``
-
-#. Checkout Clang:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/tools``
-   * ``svn co http://llvm.org/svn/llvm-project/cfe/trunk clang``
-
-#. Checkout Extra Clang Tools **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/tools/clang/tools``
-   * ``svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra``
-
-#. Checkout LLD linker **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/tools``
-   * ``svn co http://llvm.org/svn/llvm-project/lld/trunk lld``
-
-#. Checkout Polly Loop Optimizer **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/tools``
-   * ``svn co http://llvm.org/svn/llvm-project/polly/trunk polly``
-
-#. Checkout Compiler-RT (required to build the sanitizers) **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/projects``
-   * ``svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt``
-
-#. Checkout Libomp (required for OpenMP support) **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/projects``
-   * ``svn co http://llvm.org/svn/llvm-project/openmp/trunk openmp``
-
-#. Checkout libcxx and libcxxabi **[Optional]**:
-
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/projects``
-   * ``svn co http://llvm.org/svn/llvm-project/libcxx/trunk libcxx``
-   * ``svn co http://llvm.org/svn/llvm-project/libcxxabi/trunk libcxxabi``
-
-#. Get the Test Suite Source Code **[Optional]**
+   * ``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``
 
-   * ``cd where-you-want-llvm-to-live``
-   * ``cd llvm/projects``
-   * ``svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite``
-
-#. Configure and build LLVM and Clang:
-
-   *Warning:* Make sure you've checked out *all of* the source code
-   before trying to configure with cmake.  cmake does not pickup newly
-   added source directories in incremental builds.
-
-   The build uses `CMake <CMake.html>`_. LLVM requires CMake 3.4.3 to build. It
-   is generally recommended to use a recent CMake, especially if you're
-   generating Ninja build files. This is because the CMake project is constantly
-   improving the quality of the generators, and the Ninja generator gets a lot
-   of attention.
+#. Configure and build LLVM and Clang:.
 
-   * ``cd where you want to build llvm``
+   * ``cd llvm-project``
    * ``mkdir build``
    * ``cd build``
-   * ``cmake -G <generator> [options] <path to llvm sources>``
+   * ``cmake -G <generator> [options] ../llvm``
 
      Some common generators are:
 
-     * ``Unix Makefiles`` --- for generating make-compatible parallel makefiles.
      * ``Ninja`` --- for generating `Ninja <https://ninja-build.org>`_
        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='...'`` --- semicolor-separated list of the LLVM
+       subprojects you'd like to additionally build. Can include any of: clang,
+       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. ``make``) will build all of LLVM
+     * The default target (i.e. ``ninja`` or ``make``) will build all of LLVM.
 
-     * The ``check-all`` target (i.e. ``make check-all``) will run the
+     * 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*.  Make sure you run a
-       parallel build; for ``make``, use ``make -j``.
+     * Running a serial build will be *slow*.  Make sure you run a parallel
+       build. That's already done by default in Ninja; for ``make``, use
+       ``make -j NNN`` (with an appropriate value of NNN, e.g. number of CPUs
+       you have.)
 
    * For more information see `CMake <CMake.html>`_
 
    * If you get an "internal compiler error (ICE)" or test failures, see
      `below`_.
 
 Consult the `Getting Started with LLVM`_ section for detailed information on
 configuring and compiling LLVM.  Go to `Directory Layout`_ to learn about the

 
 LLVM is known to work on the following host platforms:
 
 ================== ===================== =============
 OS                 Arch                  Compilers
 ================== ===================== =============
 Linux              x86\ :sup:`1`         GCC, Clang
 Linux              amd64                 GCC, Clang
-Linux              ARM\ :sup:`4`         GCC, Clang
+Linux              ARM                   GCC, Clang
 Linux              PowerPC               GCC, Clang
 Solaris            V9 (Ultrasparc)       GCC
 FreeBSD            x86\ :sup:`1`         GCC, Clang
 FreeBSD            amd64                 GCC, Clang
 NetBSD             x86\ :sup:`1`         GCC, Clang
 NetBSD             amd64                 GCC, Clang
 MacOS X\ :sup:`2`  PowerPC               GCC
 MacOS X            x86                   GCC, Clang
 Cygwin/Win32       x86\ :sup:`1, 3`      GCC
 Windows            x86\ :sup:`1`         Visual Studio
 Windows x64        x86-64                Visual Studio
 ================== ===================== =============
 
 .. note::
 
   #. Code generation supported for Pentium processors and up
   #. Code generation supported for 32-bit ABI only
   #. To use LLVM modules on Win32-based system, you may configure LLVM
      with ``-DBUILD_SHARED_LIBS=On``.
-  #. MCJIT not working well pre-v7, old JIT engine not supported any more.
 
 Note that Debug builds require a lot of time and disk space.  An LLVM-only build
 will need about 1-3 GB of space.  A full build of LLVM and Clang will need around
 15-20 GB of disk space.  The exact space requirements will vary by system.  (It
 is so large because of all the debugging information and the fact that the
 libraries are statically linked into multiple tools).
 
 If you are space-constrained, you can build only selected tools or only
``OBJ_ROOT``
   This is the top level directory of the LLVM object tree (i.e. the tree where
   object files and compiled programs will be placed.  It can be the same as
   SRC_ROOT).
 
 Unpacking the LLVM Archives
 ---------------------------
 
 If you have the LLVM distribution, you will need to unpack it before you can
-begin to compile it.  LLVM is distributed as a set of two files: the LLVM suite
-and the LLVM GCC front end compiled for your platform.  There is an additional
-test suite that is optional.  Each file is a TAR archive that is compressed with
-the gzip program.
+begin to compile it.  LLVM is distributed as a number of different
+subprojects. Each one has its own download which is a TAR archive that is
+compressed with the gzip program.
 
 The files are as follows, with *x.y* marking the version number:
 
 ``llvm-x.y.tar.gz``
 
   Source release for the LLVM libraries and tools.
 
-``llvm-test-x.y.tar.gz``
+``cfe-x.y.tar.gz``
 
-  Source release for the LLVM test-suite.
+  Source release for the Clang frontend.
 
 .. _checkout:
 
-Checkout LLVM from Subversion
------------------------------
-
-If you have access to our Subversion repository, you can get a fresh copy of the
-entire source code.  All you need to do is check it out from Subversion as
-follows:
-
-* ``cd where-you-want-llvm-to-live``
-* Read-Only: ``svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm``
-* Read-Write: ``svn co https://[e-mail]/svn/llvm-project/llvm/trunk llvm``
-
-This will create an '``llvm``' directory in the current directory and fully
-populate it with the LLVM source code, Makefiles, test directories, and local
-copies of documentation files.
-
-If you want to get a specific release (as opposed to the most recent revision),
-you can check it out from the '``tags``' directory (instead of '``trunk``'). The
-following releases are located in the following subdirectories of the '``tags``'
-directory:
+Checkout LLVM from Git
+----------------------
 
-* Release 3.5.0 and later: **RELEASE_350/final** and so on
-* Release 2.9 through 3.4: **RELEASE_29/final** and so on
-* Release 1.1 through 2.8: **RELEASE_11** and so on
-* Release 1.0: **RELEASE_1**
-
-If you would like to get the LLVM test suite (a separate package as of 1.4), you
-get it from the Subversion repository:
-
-.. code-block:: console
-
-  % cd llvm/projects
-  % svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
-
-By placing it in the ``llvm/projects``, it will be automatically configured by
-the LLVM cmake configuration.
-
-Git Mirror
-----------
-
-Git mirrors are available for a number of LLVM subprojects. These mirrors sync
-automatically with each Subversion commit and contain all necessary git-svn
-marks (so, you can recreate git-svn metadata locally). Note that right now
-mirrors reflect only ``trunk`` for each project.
+You can also checkout the source code for LLVM from Git. While the LLVM
+project's official source-code repository is Subversion, we are in the process
+of migrating to git. We currently recommend that all developers use Git for
+day-to-day development.
 
 .. note::
 
-  On Windows, first you will want to do ``git config --global core.autocrlf
-  false`` before you clone. This goes a long way toward ensuring that
-  line-endings will be handled correctly (the LLVM project mostly uses Linux
-  line-endings).
-
-You can do the read-only Git clone of LLVM via:
-
-.. code-block:: console
-
-  % git clone https://git.llvm.org/git/llvm.git/
-
-If you want to check out clang too, run:
-
-.. code-block:: console
-
-  % cd llvm/tools
-  % git clone https://git.llvm.org/git/clang.git/
-
-If you want to check out compiler-rt (required to build the sanitizers), run:
-
-.. code-block:: console
-
-  % cd llvm/projects
-  % git clone https://git.llvm.org/git/compiler-rt.git/
-
-If you want to check out libomp (required for OpenMP support), run:
-
-.. code-block:: console
-
-  % cd llvm/projects
-  % git clone https://git.llvm.org/git/openmp.git/
-
-If you want to check out libcxx and libcxxabi (optional), run:
-
-.. code-block:: console
-
-  % cd llvm/projects
-  % git clone https://git.llvm.org/git/libcxx.git/
-  % git clone https://git.llvm.org/git/libcxxabi.git/
+  Passing ``--config core.autocrlf=false`` should not be required in
+  the future after we adjust the .gitattribute settings correctly, but
+  is required for Windows users at the time of this writing.
+
+Simply run: `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`
+
+This will create an '``llvm-project``' directory in the current directory and
+fully populate it with all of the source code, test directories, and local
+copies of documentation files for LLVM and all the related subprojects. Note
+that unlike the tarballs, which contain each subproject in a separate file, the
+git repository contains all of the projects together.
 
-If you want to check out the Test Suite Source Code (optional), run:
-
-.. code-block:: console
-
-  % cd llvm/projects
-  % git clone https://git.llvm.org/git/test-suite.git/
-
-Since the upstream repository is in Subversion, you should use ``git
-pull --rebase`` instead of ``git pull`` to avoid generating a non-linear history
-in your clone.  To configure ``git pull`` to pass ``--rebase`` by default on the
-master branch, run the following command:
-
-.. code-block:: console
-
-  % git config branch.master.rebase true
+If you want to get a specific release (as opposed to the most recent revision),
+you can check out a tag after cloning the repository. E.g., `git checkout
+llvmorg-6.0.1` inside the ``llvm-project`` directory created by the above
+command.  Use `git tag -l` to list all of them.
 
-Sending patches with Git
-^^^^^^^^^^^^^^^^^^^^^^^^
+Sending patches
+^^^^^^^^^^^^^^^
 
 Please read `Developer Policy <DeveloperPolicy.html#one-off-patches>`_, too.
 
-Assume ``master`` points the upstream and ``mybranch`` points your working
-branch, and ``mybranch`` is rebased onto ``master``.  At first you may check
-sanity of whitespaces:
+We don't currently accept github pull requests, you'so ll need to send
+patches either via emailing to llvm-commits, or via :ref:`Phabricator
+<phabricator-reviews>`.
+
+Assume ``origin/master`` points the upstream and ``mybranch`` points your
+working branch, and ``mybranch`` is rebased onto ``origin/master``.  At first
+you may check sanity of whitespaces:
 
 .. code-block:: console
 
-  % git diff --check master..mybranch
+  % git diff --check origin/master..mybranch
 
 The easiest way to generate a patch is as below:
 
 .. code-block:: console
 
-  % git diff master..mybranch > /path/to/mybranch.diff
+  % git diff origin/master..mybranch > /path/to/mybranch.diff
 
 It is a little different from svn-generated diff. git-diff-generated diff has
 prefixes like ``a/`` and ``b/``. Don't worry, most developers might know it
 could be accepted with ``patch -p1 -N``.
 
-But you may generate patchset with git-format-patch. It generates by-each-commit
-patchset. To generate patch files to attach to your article:
+You may also generate a patchset with git-format-patch. It generates
+by-each-commit patchset. To generate patch files to attach to your
+article:
 
 .. code-block:: console
 
-  % git format-patch --no-attach master..mybranch -o /path/to/your/patchset
+  % git format-patch --no-attach origin/master..mybranch -o /path/to/your/patchset
 
 If you would like to send patches directly, you may use git-send-email or
 git-imap-send. Here is an example to generate the patchset in Gmail's [Drafts].
 
 .. code-block:: console
 
   % git format-patch --attach master..mybranch --stdout | git imap-send
 
[imap]
         sslverify = false
   ; in English
         folder = "[Gmail]/Drafts"
   ; example for Japanese, "Modified UTF-7" encoded.
         folder = "[Gmail]/&Tgtm+DBN-"
   ; example for Traditional Chinese
         folder = "[Gmail]/&g0l6Pw-"
 
-.. _developers-work-with-git-svn:
-
-For developers to work with git-svn
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To set up clone from which you can submit code using ``git-svn``, run:
-
-.. code-block:: console
-
-  % git clone https://git.llvm.org/git/llvm.git/
-  % cd llvm
-  % git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username>
-  % git config svn-remote.svn.fetch :refs/remotes/origin/master
-  % git svn rebase -l  # -l avoids fetching ahead of the git mirror.
-
-  # If you have clang too:
-  % cd tools
-  % git clone https://git.llvm.org/git/clang.git/
-  % cd clang
-  % git svn init https://llvm.org/svn/llvm-project/cfe/trunk --username=<username>
-  % git config svn-remote.svn.fetch :refs/remotes/origin/master
-  % git svn rebase -l
-
-Likewise for compiler-rt, libomp and test-suite.
-
-To update this clone without generating git-svn tags that conflict with the
-upstream Git repo, run:
-
-.. code-block:: console
-
-  % git fetch && (cd tools/clang && git fetch)  # Get matching revisions of both trees.
-  % git checkout master
-  % git svn rebase -l
-  % (cd tools/clang &&
-     git checkout master &&
-     git svn rebase -l)
-
-Likewise for compiler-rt, libomp and test-suite.
-
-This leaves your working directories on their master branches, so you'll need to
-``checkout`` each working branch individually and ``rebase`` it on top of its
-parent branch.
-
-For those who wish to be able to update an llvm repo/revert patches easily using
-git-svn, please look in the directory for the scripts ``git-svnup`` and
-``git-svnrevert``.
-
-To perform the aforementioned update steps go into your source directory and
-just type ``git-svnup`` or ``git svnup`` and everything will just work.
-
-If one wishes to revert a commit with git-svn, but do not want the git hash to
-escape into the commit message, one can use the script ``git-svnrevert`` or
-``git svnrevert`` which will take in the git hash for the commit you want to
-revert, look up the appropriate svn revision, and output a message where all
-references to the git hash have been replaced with the svn revision.
-
-To commit back changes via git-svn, use ``git svn dcommit``:
-
-.. code-block:: console
-
-  % git svn dcommit
-
-Note that git-svn will create one SVN commit for each Git commit you have pending,
-so squash and edit each commit before executing ``dcommit`` to make sure they all
-conform to the coding standards and the developers' policy.
-
-On success, ``dcommit`` will rebase against the HEAD of SVN, so to avoid conflict,
-please make sure your current branch is up-to-date (via fetch/rebase) before
-proceeding.
-
-The git-svn metadata can get out of sync after you mess around with branches and
-``dcommit``. When that happens, ``git svn dcommit`` stops working, complaining
-about files with uncommitted changes. The fix is to rebuild the metadata:
-
-.. code-block:: console
-
-  % rm -rf .git/svn
-  % git svn rebase -l
-
-Please, refer to the Git-SVN manual (``man git-svn``) for more information.
-
-For developers to work with a git monorepo
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-.. note::
-
-   This set-up is using an unofficial mirror hosted on GitHub, use with caution.
-
-To set up a clone of all the llvm projects using a unified repository:
-
-.. code-block:: console
-
-  % export TOP_LEVEL_DIR=`pwd`
-  % git clone https://github.com/llvm-project/llvm-project-20170507/ llvm-project
-  % cd llvm-project
-  % git config branch.master.rebase true
-
-You can configure various build directory from this clone, starting with a build
-of LLVM alone:
-
-.. code-block:: console
-
-  % cd $TOP_LEVEL_DIR
-  % mkdir llvm-build && cd llvm-build
-  % cmake -GNinja ../llvm-project/llvm
-
-Or lldb:
-
-.. code-block:: console
-
-  % cd $TOP_LEVEL_DIR
-  % mkdir lldb-build && cd lldb-build
-  % cmake -GNinja ../llvm-project/llvm -DLLVM_ENABLE_PROJECTS=lldb
-
-Or a combination of multiple projects:
-
-.. code-block:: console
-
-  % cd $TOP_LEVEL_DIR
-  % mkdir clang-build && cd clang-build
-  % cmake -GNinja ../llvm-project/llvm -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi"
+For developers to commit changes from Git
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 A helper script is provided in ``llvm/utils/git-svn/git-llvm``. After you add it
-to your path, you can push committed changes upstream with ``git llvm push``.
+to your path, you can push committed changes upstream with ``git llvm
+push``. While this creates a Subversion checkout and patches it under the hood,
+it does not require you to have interaction with it.
 
 .. code-block:: console
 
   % export PATH=$PATH:$TOP_LEVEL_DIR/llvm-project/llvm/utils/git-svn/
   % git llvm push
 
-While this is using SVN under the hood, it does not require any interaction from
-you with git-svn.
-After a few minutes, ``git pull`` should get back the changes as they were
-committed. Note that a current limitation is that ``git`` does not directly
-record file rename, and thus it is propagated to SVN as a combination of
-delete-add instead of a file rename.
+Within a couple minutes after pushing to subversion, the svn commit will have
+been converted back to a Git commit, and made its way into the official Git
+repository. At that point, ``git pull`` should get back the changes as they were
+committed.
+
+You'll likely want to ``git pull --rebase`` to get the official git commit
+downloaded back to your repository. The SVN revision numbers of each commit can
+be found at the end of the commit message, e.g. ``llvm-svn: 350914``.
 
-The SVN revision of each monorepo commit can be found in the commit notes.  git
-does not fetch notes by default. The following commands will fetch the notes and
-configure git to fetch future notes. Use ``git notes show $commit`` to look up
-the SVN revision of a git commit. The notes show up ``git log``, and searching
-the log is currently the recommended way to look up the git commit for a given
-SVN revision.
+Checkout via SVN (deprecated)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-.. code-block:: console
-
-  % git config --add remote.origin.fetch +refs/notes/commits:refs/notes/commits
-  % git fetch
+Until we have fully migrated to Git, you may also get a fresh copy of
+the code from the official Subversion repository.
 
-If you are using `arc` to interact with Phabricator, you need to manually put it
-at the root of the checkout:
+* ``cd where-you-want-llvm-to-live``
+* Read-Only: ``svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm``
+* Read-Write: ``svn co https://[e-mail]/svn/llvm-project/llvm/trunk llvm``
 
-.. code-block:: console
+This will create an '``llvm``' directory in the current directory and fully
+populate it with the LLVM source code, Makefiles, test directories, and local
+copies of documentation files.
 
-  % cd $TOP_LEVEL_DIR
-  % cp llvm/.arcconfig ./
-  % mkdir -p .git/info/
-  % echo .arcconfig >> .git/info/exclude
+If you want to get a specific release (as opposed to the most recent revision),
+you can check it out from the '``tags``' directory (instead of '``trunk``'). The
+following releases are located in the following subdirectories of the '``tags``'
+directory:
 
+* Release 3.5.0 and later: **RELEASE_350/final** and so on
+* Release 2.9 through 3.4: **RELEASE_29/final** and so on
+* Release 1.1 through 2.8: **RELEASE_11** and so on
+* Release 1.0: **RELEASE_1**
 
 Local LLVM Configuration
 ------------------------
 
-Once checked out from the Subversion repository, the LLVM suite source code must
-be configured before being built. This process uses CMake.
-Unlinke the normal ``configure`` script, CMake
-generates the build files in whatever format you request as well as various
-``*.inc`` files, and ``llvm/include/Config/config.h``.
+Once checked out repository, the LLVM suite source code must be configured
+before being built. This process uses CMake.  Unlinke the normal ``configure``
+script, CMake generates the build files in whatever format you request as well
+as various ``*.inc`` files, and ``llvm/include/Config/config.h``.
 
 Variables are passed to ``cmake`` on the command line using the format
 ``-D<variable name>=<value>``. The following variables are some common options
 used by people developing LLVM.
 
 +-------------------------+----------------------------------------------------+
 | Variable                | Purpose                                            |
 +=========================+====================================================+
 | CMAKE_C_COMPILER        | Tells ``cmake`` which C compiler to use. By        |
 |                         | default, this will be /usr/bin/cc.                 |
 +-------------------------+----------------------------------------------------+
 | CMAKE_CXX_COMPILER      | Tells ``cmake`` which C++ compiler to use. By      |
 |                         | default, this will be /usr/bin/c++.                |
 +-------------------------+----------------------------------------------------+
 | CMAKE_BUILD_TYPE        | Tells ``cmake`` what type of build you are trying  |
 |                         | to generate files for. Valid options are Debug,    |
 |                         | Release, RelWithDebInfo, and MinSizeRel. Default   |
 |                         | is Debug.                                          |
 +-------------------------+----------------------------------------------------+
 | CMAKE_INSTALL_PREFIX    | Specifies the install directory to target when     |
 |                         | running the install action of the build files.     |
 +-------------------------+----------------------------------------------------+
 | LLVM_TARGETS_TO_BUILD   | A semicolon delimited list controlling which       |
-|                         | targets will be built and linked into llc. This is |
-|                         | equivalent to the ``--enable-targets`` option in   |
-|                         | the configure script. The default list is defined  |
-|                         | as ``LLVM_ALL_TARGETS``, and can be set to include |
+|                         | targets will be built and linked into llvm.        |
+|                         | The default list is defined as                     |
+|                         | ``LLVM_ALL_TARGETS``, and can be set to include    |
 |                         | out-of-tree targets. The default value includes:   |
 |                         | ``AArch64, AMDGPU, ARM, BPF, Hexagon, Mips,        |
 |                         | MSP430, NVPTX, PowerPC, Sparc, SystemZ, X86,       |
 |                         | XCore``.                                           |
+|                         |                                                    |
 +-------------------------+----------------------------------------------------+
 | LLVM_ENABLE_DOXYGEN     | Build doxygen-based documentation from the source  |
 |                         | code This is disabled by default because it is     |
 |                         | slow and generates a lot of output.                |
 +-------------------------+----------------------------------------------------+
+| LLVM_ENABLE_PROJECTS    | A semicolon-delimited list selecting which of the  |
+|                         | other LLVM subprojects to additionally build. (Only|
+|                         | effective when using a side-by-side project layout |
+|                         | e.g. via git). The default list is empty. Can      |
+|                         | include: clang, libcxx, libcxxabi, libunwind, lldb,|
+|                         | compiler-rt, lld, polly, or debuginfo-tests.       |
++-------------------------+----------------------------------------------------+
 | LLVM_ENABLE_SPHINX      | Build sphinx-based documentation from the source   |
 |                         | code. This is disabled by default because it is    |
 |                         | slow and generates a lot of output. Sphinx version |
 |                         | 1.5 or later recommended.                          |
 +-------------------------+----------------------------------------------------+
 | LLVM_BUILD_LLVM_DYLIB   | Generate libLLVM.so. This library contains a       |
 |                         | default set of LLVM components that can be         |
 |                         | overridden with ``LLVM_DYLIB_COMPONENTS``. The     |

 ``llvm/include/llvm/Support``
 
   Generic support libraries provided with LLVM but not necessarily specific to
   LLVM. For example, some C++ STL utilities and a Command Line option processing
   library store header files here.
 
 ``llvm/include/llvm/Config``
 
-  Header files configured by the ``configure`` script.
-  They wrap "standard" UNIX and C header files.  Source code can include these
-  header files which automatically take care of the conditional #includes that
-  the ``configure`` script generates.
+  Header files configured by ``cmake``.  They wrap "standard" UNIX and
+  C header files.  Source code can include these header files which
+  automatically take care of the conditional #includes that ``cmake``
+  generates.
 
 ``llvm/lib``
 ------------
 
 Most source files are here. By putting code in libraries, LLVM makes it easy to
 share code among the `tools`_.
 
 ``llvm/lib/IR/``

 -------------
 
 Feature and regression tests and other sanity checks on LLVM infrastructure. These
 are intended to run quickly and cover a lot of territory without being exhaustive.
 
 ``test-suite``
 --------------
 
-A comprehensive correctness, performance, and benchmarking test suite for LLVM.
-Comes in a separate Subversion module because not every LLVM user is interested
-in such a comprehensive suite. For details see the :doc:`Testing Guide
-<TestingGuide>` document.
+A comprehensive correctness, performance, and benchmarking test suite
+for LLVM.  This comes in a ``separate git repository
+<https://github.com/llvm/llvm-test-suite>``, because it contains a
+large amount of third-party code under a variety of licenses. For
+details see the :doc:`Testing Guide <TestingGuide>` document.
 
 .. _tools:
 
 ``llvm/tools``
 --------------
 
 Executables built out of the libraries
 above, which form the main part of the user interface.  You can always get help

llvm/docs/Phabricator.rst

+.. _phabricator-reviews:
+
 =============================
 Code Reviews with Phabricator
 =============================
 
 .. contents::
   :local:
 
 If you prefer to use a web user interface for code reviews, you can now submit

 the reviewed patch as you would normally.
 
 Note that if you commit the change without using Arcanist and forget to add the
 ``Differential Revision`` line to your commit message then it is recommended
 that you close the review manually. In the web UI, under "Leap Into Action" put
 the SVN revision number in the Comment, set the Action to "Close Revision" and
 click Submit.  Note the review must have been Accepted first.
 
-Subversion and Arcanist
-^^^^^^^^^^^^^^^^^^^^^^^
-
-On a clean Subversion working copy run the following (where ``<Revision>`` is
-the Phabricator review number):
-
-::
-
-  arc patch D<Revision>
-  arc commit --revision D<Revision>
-
-The first command will take the latest version of the reviewed patch and apply it to the working
-copy. The second command will commit this revision to trunk.
-
-git-svn and Arcanist
-^^^^^^^^^^^^^^^^^^^^
-
-This presumes that the git repository has been configured as described in :ref:`developers-work-with-git-svn`.
+git and Arcanist
+^^^^^^^^^^^^^^^^
 
 On a clean Git repository on an up to date ``master`` branch run the
 following (where ``<Revision>`` is the Phabricator review number):
 
 ::
 
   arc patch D<Revision>
 
 
 This will create a new branch called ``arcpatch-D<Revision>`` based on the
 current ``master`` and will create a commit corresponding to ``D<Revision>`` with a
 commit message derived from information in the Phabricator review.
 
 Check you are happy with the commit message and amend it if necessary. Now switch to
 the ``master`` branch and add the new commit to it and commit it to trunk. This
 can be done by running the following:
 
 ::
 
   git checkout master
   git merge --ff-only arcpatch-D<Revision>
-  git svn dcommit
+  git llvm push
+
+Subversion and Arcanist
+^^^^^^^^^^^^^^^^^^^^^^^
+
+On a clean Subversion working copy run the following (where ``<Revision>`` is
+the Phabricator review number):
+
+::
 
+  arc patch D<Revision>
+  arc commit --revision D<Revision>
 
+The first command will take the latest version of the reviewed patch and apply
+it to the working copy. The second command will commit this revision to trunk.
 
 Abandoning a change
 -------------------
 
 If you decide you should not commit the patch, you should explicitly abandon
 the review so that reviewers don't think it is still open. In the web UI,
 scroll to the bottom of the page where normally you would enter an overall
 comment. In the drop-down Action list, which defaults to "Comment," you should

llvm/docs/TypeMetadata.rst

define void @main() {
       %d02 = call i1 @bar(i32* getelementptr ([2 x i32]* @d, i32 0, i32 0)) ; returns 0
       %d12 = call i1 @bar(i32* getelementptr ([2 x i32]* @d, i32 0, i32 1)) ; returns 1
       %e = call i1 @baz(void ()* @e) ; returns 1
       %f = call i1 @baz(void ()* @f) ; returns 0
       %g = call i1 @baz(void ()* @g) ; returns 1
       ret void
     }
 
-.. _GlobalLayoutBuilder: http://git.llvm.org/klaus/llvm/blob/master/include/llvm/Transforms/IPO/LowerTypeTests.h
+.. _GlobalLayoutBuilder: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Transforms/IPO/LowerTypeTests.h

llvm/docs/Vectorizers.rst

 
 The Loop Vectorizer uses a cost model to decide when it is profitable to unroll loops.
 The decision to unroll the loop depends on the register pressure and the generated code size. 
 
 Performance
 -----------
 
 This section shows the execution time of Clang on a simple benchmark:
-`gcc-loops <http://llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/UnitTests/Vectorizer/>`_.
+`gcc-loops <https://github.com/llvm/llvm-test-suite/tree/master/SingleSource/UnitTests/Vectorizer>`_.
 This benchmarks is a collection of loops from the GCC autovectorization
 `page <http://gcc.gnu.org/projects/tree-ssa/vectorization.html>`_ by Dorit Nuzman.
 
 The chart below compares GCC-4.7, ICC-13, and Clang-SVN with and without loop vectorization at -O3, tuned for "corei7-avx", running on a Sandybridge iMac.
 The Y-axis shows the time in msec. Lower is better. The last column shows the geomean of all the kernels.
 
 .. image:: gcc-loops.png
 

llvm/docs/index.rst

 :doc:`ExtendingLLVM`
   Look here to see how to add instructions and intrinsics to LLVM.
 
 `Doxygen generated documentation <http://llvm.org/doxygen/>`_
   (`classes <http://llvm.org/doxygen/inherits.html>`_)
 
 `Documentation for Go bindings <http://godoc.org/llvm.org/llvm/bindings/go/llvm>`_
 
-`ViewVC Repository Browser <http://llvm.org/viewvc/>`_
+`Github Source Repository Browser <http://github.com/llvm/llvm-project//>`_
    ..
 
 :doc:`CompilerWriterInfo`
   A list of helpful links for compiler writers.
 
 :doc:`LibFuzzer`
   A library for writing in-process guided fuzzers.
 

llvm/test/Transforms/SLPVectorizer/AArch64/matmul.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt < %s -basicaa -slp-vectorizer -S -mtriple=aarch64-unknown-unknown -mcpu=cortex-a53 | FileCheck %s
 
 target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 ; This test is reduced from the matrix multiplication benchmark in the test-suite:
-; http://www.llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/Benchmarks/Misc/matmul_f64_4x4.c
+; https://github.com/llvm/llvm-test-suite/tree/master/SingleSource/Benchmarks/Misc/matmul_f64_4x4.c
 ; The operations here are expected to be vectorized to <2 x double>.
 ; Otherwise, performance will suffer on Cortex-A53.
 
 define void @wrap_mul4(double* nocapture %Out, [2 x double]* nocapture readonly %A, [4 x double]* nocapture readonly %B) {
 ; CHECK-LABEL: @wrap_mul4(
 ; CHECK-NEXT:    [[ARRAYIDX1_I:%.*]] = getelementptr inbounds [2 x double], [2 x double]* [[A:%.*]], i64 0, i64 0
 ; CHECK-NEXT:    [[TEMP:%.*]] = load double, double* [[ARRAYIDX1_I]], align 8
 ; CHECK-NEXT:    [[ARRAYIDX3_I:%.*]] = getelementptr inbounds [4 x double], [4 x double]* [[B:%.*]], i64 0, i64 0

llvm/test/Transforms/SLPVectorizer/AArch64/tsc-s352.ll

 ; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
 ; RUN: opt < %s -slp-vectorizer -S -mtriple=aarch64-unknown-unknown -mcpu=cortex-a53 | FileCheck %s
 
 target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
 
 ; This test is reduced from the TSVC evaluation of vectorizers:
-; http://www.llvm.org/viewvc/llvm-project/test-suite/trunk/MultiSource/Benchmarks/TSVC/LoopRerolling-flt/tsc.c?view=log
+; https://github.com/llvm/llvm-test-suite/commits/master/MultiSource/Benchmarks/TSVC/LoopRerolling-flt/tsc.c
 ; Two loads and an fmul are expected to be vectorized to <2 x float>.
 ; Otherwise, performance will suffer on Cortex-A53.
 ; See https://bugs.llvm.org/show_bug.cgi?id=36280 for more details.
 
 %struct.GlobalData = type { [32000 x float], [3 x i32], [4 x i8], [32000 x float], [5 x i32], [12 x i8], [32000 x float], [7 x i32], [4 x i8], [32000 x float], [11 x i32], [4 x i8], [32000 x float], [13 x i32], [12 x i8], [256 x [256 x float]], [17 x i32], [12 x i8], [256 x [256 x float]], [19 x i32], [4 x i8], [256 x [256 x float]], [23 x i32], [4 x i8], [256 x [256 x float]] }
 
 @global_data = common dso_local global %struct.GlobalData zeroinitializer, align 16