Summary:
This document is an attempt to provide a guide for best practices for using the LLVM build system to generate distributable LLVM-based tools.
Most of the document is geared toward distributions of LLVM-based toolchains, but much of it also applies to distributing other LLVM-based tools and libraries.
Reviewers: tstellar, phosek, jroelofs, hans, sylvestre.ledru
Reviewed By: tstellar
Subscribers: smeenai, dschuff, arphaman, winksaville, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62040
llvm-svn: 361272
official Git repository.
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.
Differential Revision: https://reviews.llvm.org/D56654
llvm-svn: 351130
When multiple loop transformation are defined in a loop's metadata, their order of execution is defined by the order of their respective passes in the pass pipeline. For instance, e.g.
#pragma clang loop unroll_and_jam(enable)
#pragma clang loop distribute(enable)
is the same as
#pragma clang loop distribute(enable)
#pragma clang loop unroll_and_jam(enable)
and will try to loop-distribute before Unroll-And-Jam because the LoopDistribute pass is scheduled after UnrollAndJam pass. UnrollAndJamPass only supports one inner loop, i.e. it will necessarily fail after loop distribution. It is not possible to specify another execution order. Also,t the order of passes in the pipeline is subject to change between versions of LLVM, optimization options and which pass manager is used.
This patch adds 'followup' attributes to various loop transformation passes. These attributes define which attributes the resulting loop of a transformation should have. For instance,
!0 = !{!0, !1, !2}
!1 = !{!"llvm.loop.unroll_and_jam.enable"}
!2 = !{!"llvm.loop.unroll_and_jam.followup_inner", !3}
!3 = !{!"llvm.loop.distribute.enable"}
defines a loop ID (!0) to be unrolled-and-jammed (!1) and then the attribute !3 to be added to the jammed inner loop, which contains the instruction to distribute the inner loop.
Currently, in both pass managers, pass execution is in a fixed order and UnrollAndJamPass will not execute again after LoopDistribute. We hope to fix this in the future by allowing pass managers to run passes until a fixpoint is reached, use Polly to perform these transformations, or add a loop transformation pass which takes the order issue into account.
For mandatory/forced transformations (e.g. by having been declared by #pragma omp simd), the user must be notified when a transformation could not be performed. It is not possible that the responsible pass emits such a warning because the transformation might be 'hidden' in a followup attribute when it is executed, or it is not present in the pipeline at all. For this reason, this patche introduces a WarnMissedTransformations pass, to warn about orphaned transformations.
Since this changes the user-visible diagnostic message when a transformation is applied, two test cases in the clang repository need to be updated.
To ensure that no other transformation is executed before the intended one, the attribute `llvm.loop.disable_nonforced` can be added which should disable transformation heuristics before the intended transformation is applied. E.g. it would be surprising if a loop is distributed before a #pragma unroll_and_jam is applied.
With more supported code transformations (loop fusion, interchange, stripmining, offloading, etc.), transformations can be used as building blocks for more complex transformations (e.g. stripmining+stripmining+interchange -> tiling).
Reviewed By: hfinkel, dmgreen
Differential Revision: https://reviews.llvm.org/D49281
Differential Revision: https://reviews.llvm.org/D55288
llvm-svn: 348944
Summary:
Basic documentation of the Stack Safety Analysis.
It will be improved during review and upstream of an implementation.
Reviewers: kcc, eugenis, vlad.tsyrklevich, glider
Reviewed By: vlad.tsyrklevich
Subscribers: arphaman, llvm-commits
Differential Revision: https://reviews.llvm.org/D53336
llvm-svn: 347612
Document what is expected during:
* triaging
* actively working on a bug
* closing/resolving
Also document how we maintain:
* product/component breakdown
* default-cc lists per component
Differential Revision: https://reviews.llvm.org/D53691
llvm-svn: 346299
Depending on who you ask, PGO grants a 15%-25% improvement in build
times when using clang. Sadly, hooking everything up properly to
generate a profile and apply it to clang isn't always straightforward.
This script (and the accompanying docs) aim to make this process easier;
ideally, a single invocation of the given script.
In terms of testing, I've got a cronjob on my Debian box that's meant to
run this a few times per week, and I tried manually running it on a puny
Gentoo box I have (four whole Atom cores!). Nothing obviously broke.
¯\_(ツ)_/¯
I don't know if we have a Python style guide, so I just shoved this
through yapf with all the defaults on.
Finally, though the focus is clang at the moment, the hope is that this
is easily applicable to other LLVM-y tools with minimal effort (e.g.
lld, opt, ...). Hence, this lives in llvm/utils and tries to be somewhat
ambiguous about naming.
Differential Revision: https://reviews.llvm.org/D53598
llvm-svn: 345427
Add a list of benchmarks, applications and algorithms which are under
discussion to be added to the test-suite.
The initial list includes the the benchmarks mentioned at
https://llvm.org/PR34216, missing SPEC benchmarks, some image processing
algorithms and a few others. The bug tracker only allows adding to the
discussion, not removing, commenting, adding details to individual
benchmarks.
The first proposal was to add these benchmark into the test-suite
repository, but after a discussion, adding it to llvm/docs/Proposals
seem more appropriate. One advantage is that llvm.org will have a
browsable web page with these suggestions.
Suggested-by: Hal Finkel
Differential Revision: https://reviews.llvm.org/D46714
llvm-svn: 345074
System Library has been a long deprecated term along with the path lib/System, having been superseded/renamed
to the Support Library a long time ago. These patches reflect those changes in documentation as well as
update some outdated examples and provide context to the origin of the Support Library.
Differential Revision: https://reviews.llvm.org/D52107
llvm-svn: 342500
- Remove duplication: Both TestingGuide and TestSuiteMakefileGuide
would give a similar overview over the test-suite.
- Present cmake/lit as the default/normal way of running the test-suite:
- Move information about the cmake/lit testsuite into the new
TestSuiteGuide.rst file. Mark the remaining information in
TestSuiteMakefilesGuide.rst as deprecated.
- General simplification and shorting of language.
- Remove paragraphs about tests known to fail as everything should pass
nowadays.
- Remove paragraph about zlib requirement; it's not required anymore
since we copied a zlib source snapshot into the test-suite.
- Remove paragraph about comparison with "native compiler". Correctness is
always checked against reference outputs nowadays.
- Change cmake/lit quickstart section to recommend `pip` for installing
lit and use `CMAKE_C_COMPILER` and a cache file in the example as that
is what most people will end up doing anyway. Also a section about
compare.py to quickstart.
- Document `Bitcode` and `MicroBenchmarks` directories.
- Add section with commonly used cmake configuration options.
- Add section about showing and comparing result files via compare.py.
- Add section about using external benchmark suites.
- Add section about using custom benchmark suites.
- Add section about profile guided optimization.
- Add section about cross-compilation and running on external devices.
Differential Revision: https://reviews.llvm.org/D51465
llvm-svn: 341260
Sphinx.
We think the bot is updated now, so trying this again. I'm landing it
(with permission) as Michael is at a con at the moment.
Actual patch largely by Michael Spencer.
Differential Revision: https://reviews.llvm.org/D44910
llvm-svn: 338977
This new page acts as an entry point for (new) contributors to LLVM and
provides information about
* What to contribute
* How to submit a patch
* Where to start to learn more about LLVM's architecture and internals.
This version of the page duplicates some information from the
DeveloperPolicy and Phabricator pages. Subsequent changes should work
towards moving information for new developers to this page, where it
makes sense.
Reviewers: reames, probinson, kristof.beyls, silvas, rengolin, asb
Reviewed By: silvas
Differential Revision: https://reviews.llvm.org/D41665
llvm-svn: 321804
This document contains information on how to cross-compile the compiler-rt
builtins library for several flavours of Arm target and how to test the
libraries using qemu.
Differential Revision: https://reviews.llvm.org/D39600
llvm-svn: 317554
Summary: Resubmission of D37937. Fixed i386 target building (conversion from std::size_t& to uint64_t& failed). Fixed documentation warning failure about docs/CFIVerify.rst not being in the tree.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Patch by Mitch Phillips
Subscribers: sbc100, mgorny, pcc, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D38089
llvm-svn: 313809
Summary: Resubmission of D37937. Fixed i386 target building (conversion from std::size_t& to uint64_t& failed). Fixed documentation warning failure about docs/CFIVerify.rst not being in the tree.
Reviewers: vlad.tsyrklevich
Reviewed By: vlad.tsyrklevich
Patch by Mitch Phillips
Subscribers: mgorny, pcc, llvm-commits, kcc
Differential Revision: https://reviews.llvm.org/D38089
llvm-svn: 313798
Summary:
Adding a new restructuredText file to document the trace format produced with
an FDR mode handler and read by llvm-xray toolset.
Fixed two problems in the documentation from differential review. One bad table
and a missing link in the toc.
Original commit was e97c5836a77db803fe53319c53f3bf8e8b26d2b7.
Reviewers: dberris, pelikan
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D36041
llvm-svn: 309891
Following the request made in https://reviews.llvm.org/D32871, the
general documentation of the Vectorization Plan is hereby placed
under docs/Proposals.
llvm-svn: 304161
Summary:
This document is an attempt at showing how XRay could be used to debug
latency issues with LLVM tools, and how to use the llvm-xray tool to
analyse XRay traces.
Reviewers: echristo, mehdi_amini, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31493
llvm-svn: 299133
Summary:
This is the initial version of the documentation for how to use XRay as
it stands in LLVM, Clang, and compiler-rt. We leave some room for later
expansion mentioining what is work in progress and what could be
expected moving forward.
We also give a high level overview of future work that's both ongoing
and planned.
Reviewers: echristo, dblaikie, chandlerc
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D26386
llvm-svn: 286319
This reflects the current state of Global ISel. As progress is
made, we'll document our design decisions in it.
Comments very welcome!
llvm-svn: 286002
This document describes the proposal to move to GitHub, and
compare the two proposals through various workflow examples,
presenting the current set of commands following by the ones
involved in each of the two proposals.
It is intended to supersede the previous "submodule proposal"
document entirely, and drive the discussion at the BoF during
the next Dev Meeting.
Differential Revision: https://reviews.llvm.org/D24167
llvm-svn: 284077
This is the first patch in the coroutine series.
It contains the documentation for the coroutine intrinsics and their usage.
Patch by Gor Nishanov!
Differential Revision: https://reviews.llvm.org/D22603
llvm-svn: 276513
Given that other proposals are making their way through, it's better if we
specify what GitHub proposal this is, in case there are others that also
involve GitHub, but not sub-modules.
llvm-svn: 276325
associated reporting guide.
I want to emphasize that at this point these are just drafts!
This is the result of very extended discussion on the mailing lists on
several different threads:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.htmlhttp://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.htmlhttp://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html
The reporting guide in particular I anticipate will be shaped somewhat
by the advisory committee when they are selected. But hopefully this
serves as a good starting point and good guidance while the advisory
committee is being sorted out.
I'd like to thank all the folks who contributed to this. Many, *many*
people worked to help with drafting, wording, suggestions, and edits.
Also, this is based on widely used existing codes of coduct as mentioned
in the text, and the original authors of those deserve many thanks as
well.
Differential Revision: http://reviews.llvm.org/D13741
llvm-svn: 274268
The bitset metadata currently used in LLVM has a few problems:
1. It has the wrong name. The name "bitset" refers to an implementation
detail of one use of the metadata (i.e. its original use case, CFI).
This makes it harder to understand, as the name makes no sense in the
context of virtual call optimization.
2. It is represented using a global named metadata node, rather than
being directly associated with a global. This makes it harder to
manipulate the metadata when rebuilding global variables, summarise it
as part of ThinLTO and drop unused metadata when associated globals are
dropped. For this reason, CFI does not currently work correctly when
both CFI and vcall opt are enabled, as vcall opt needs to rebuild vtable
globals, and fails to associate metadata with the rebuilt globals. As I
understand it, the same problem could also affect ASan, which rebuilds
globals with a red zone.
This patch solves both of those problems in the following way:
1. Rename the metadata to "type metadata". This new name reflects how
the metadata is currently being used (i.e. to represent type information
for CFI and vtable opt). The new name is reflected in the name for the
associated intrinsic (llvm.type.test) and pass (LowerTypeTests).
2. Attach metadata directly to the globals that it pertains to, rather
than using the "llvm.bitsets" global metadata node as we are doing now.
This is done using the newly introduced capability to attach
metadata to global variables (r271348 and r271358).
See also: http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21053
llvm-svn: 273729
* Renamed to be camel case, consistent with other docs.
* Fixed non-ascii characters (this is what I get for writing docs on an iPad).
llvm-svn: 263840
