summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* Use backquotes to avoid a sphinx unexpected error:Sylvestre Ledru2018-12-161-1/+1
| | | | | | Unknown target name: "bootstrap". llvm-svn: 349301
* Document the usage of BOOTSTRAP_XXX with stage2 buildsSylvestre Ledru2018-12-161-0/+9
| | | | llvm-svn: 349299
* [docs] Use correct ending quotes.Michael Kruse2018-12-121-1/+1
| | | | llvm-svn: 348947
* [Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes.Michael Kruse2018-12-124-0/+570
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Intrinsic] Signed Fixed Point Multiplication IntrinsicLeonard Chan2018-12-121-0/+70
| | | | | | | | | | | | Add an intrinsic that takes 2 signed integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D54719 llvm-svn: 348912
* [docs] Add the new Objective-C ARC intrinsics to the LangRef.Erik Pilkington2018-12-101-0/+260
| | | | | | | These were added in r348441. This mostly just points to the clang documentation to describe the intended semantics of each intrinsic. llvm-svn: 348782
* Introduce llvm.experimental.widenable_condition intrinsicMax Kazantsev2018-12-071-0/+139
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new instinsic `@llvm.experimental.widenable_condition` that allows explicit representation for guards. It is an alternative to using `@llvm.experimental.guard` intrinsic that does not contain implicit control flow. We keep finding places where `@llvm.experimental.guard` is not supported or treated too conservatively, and there are 2 reasons to that: - `@llvm.experimental.guard` has memory write side effect to model implicit control flow, and this sometimes confuses passes and analyzes that work with memory; - Not all passes and analysis are aware of the semantics of guards. These passes treat them as regular throwing call and have no idea that the condition of guard may be used to prove something. One well-known place which had caused us troubles in the past is explicit loop iteration count calculation in SCEV. Another example is new loop unswitching which is not aware of guards. Whenever a new pass appears, we potentially have this problem there. Rather than go and fix all these places (and commit to keep track of them and add support in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible. The only significant difference between guards and regular explicit branches is that guard's condition can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor, and it is always legal to go there no matter what the guard condition is. The other successor is a guarded block, and it is only legal to go there if the condition is true. This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard` intrinsic. Now a widenable guard can be represented in the CFG explicitly like this: %widenable_condition = call i1 @llvm.experimental.widenable.condition() %new_condition = and i1 %cond, %widenable_condition br i1 %new_condition, label %guarded, label %deopt guarded: ; Guarded instructions deopt: call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ] The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an `undef`, but the intrinsic prevents the optimizer from folding it early. This form should exploit all optimization boons provided to `br` instuction, and it still can be widened by replacing the result of `@llvm.experimental.widenable.condition()` with `and` with any arbitrary boolean value (as long as the branch that is taken when it is `false` has a deopt and has no side-effects). For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using implicit control flow in guards". This patch introduces this new intrinsic with respective LangRef changes and a pass that converts old-style guards (expressed as intrinsics) into the new form. The naming discussion is still ungoing. Merging this to unblock further items. We can later change the name of this intrinsic. Reviewed By: reames, fedor.sergeev, sanjoy Differential Revision: https://reviews.llvm.org/D51207 llvm-svn: 348593
* HowToBuildWithPGO.rst: Fix a few details in the manual stepsHans Wennborg2018-12-051-3/+3
| | | | | | Differential revision: https://reviews.llvm.org/D55268 llvm-svn: 348342
* MIR: Add method to stop after specific runs of passesMatt Arsenault2018-12-041-0/+5
| | | | | | | | | | Currently if you use -{start,stop}-{before,after}, it picks the first instance with the matching pass name. If you run the same pass multiple times, there's no way to distinguish them. Allow specifying a run index wih ,N to specify which you mean. llvm-svn: 348285
* [docs][AtomicExpandPass] Document the alternate lowering strategy for ↵Alex Bradbury2018-11-301-2/+18
| | | | | | | | | | | | | | | | | | | | part-word atomicrmw/cmpxchg D47882, D48130 and D48131 introduce a new lowering strategy for part-word atomicrmw/cmpxchg and uses it to lower these operations for the RISC-V target. Rather than having AtomicExpandPass produce the LL/SC loop in the IR level, it instead calculates the necessary mask values and inserts a target-specific intrinsic, which is lowered at a much later stage (after register allocation). This ensures that architecture-specific restrictions for forward-progress in LL/SC loops can be guaranteed. This patch documents this new AtomicExpandPass functionality. See the previous llvm-dev RFC for more info <http://lists.llvm.org/pipermail/llvm-dev/2018-June/123993.html>. Differential Revision: https://reviews.llvm.org/D52234 llvm-svn: 347971
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Resubmit this with no changes because I think the build was broken by a different diff. ----- The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347701
* [TableGen] Preprocessing supportVyacheslav Zakharin2018-11-271-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D54926 llvm-svn: 347686
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-271-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | until I figure out why the build is failing or timing out *************************** Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 This reverts commit a5b3c232d1e3613f23efbc3960f8e23ea70f2a79. (r347617) llvm-svn: 347628
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-271-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The prior diff had to be reverted because there were two tests that failed. I updated the two tests in this diff clang/test/Misc/pragma-attribute-supported-attributes-list.test clang/test/SemaCXX/attr-speculative-load-hardening.cpp ----- Summary from Previous Diff (Still Accurate) ----- LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54915 llvm-svn: 347617
* Remove trailing empty lineVitaly Buka2018-11-261-1/+0
| | | | llvm-svn: 347613
* [stack-safety] Analysis documentationVitaly Buka2018-11-263-0/+71
| | | | | | | | | | | | | | | | 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
* Revert "[clang][slh] add attribute for speculative load hardening"Zola Bridges2018-11-261-9/+13
| | | | | | This reverts commit 801eaf91221ba6dd6996b29ff82659ad6359e885. llvm-svn: 347588
* [clang][slh] add attribute for speculative load hardeningZola Bridges2018-11-261-13/+9
| | | | | | | | | | | | | | | | | | Summary: LLVM IR already has an attribute for speculative_load_hardening. Before this commit, when a user passed the -mspeculative-load-hardening flag to Clang, every function would have this attribute added to it. This Clang attribute will allow users to opt into SLH on a function by function basis. This can be applied to functions and Objective C methods. Reviewers: chandlerc, echristo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54555 llvm-svn: 347586
* [llvm-mca][View] Improved Retire Control Unit Statistics.Andrea Di Biagio2018-11-231-0/+4
| | | | | | | | | | | | | | | | | | | | | RetireControlUnitStatistics now reports extra information about the ROB and the avg/maximum number of entries consumed over the entire simulation. Example: Retire Control Unit - number of cycles where we saw N instructions retired: [# retired], [# cycles] 0, 109 (17.9%) 1, 102 (16.7%) 2, 399 (65.4%) Total ROB Entries: 64 Max Used ROB Entries: 35 ( 54.7% ) Average Used ROB Entries per cy: 32 ( 50.0% ) Documentation in llvm/docs/CommandGuide/llvmn-mca.rst has been updated to reflect this change. llvm-svn: 347493
* [docs] Add C++ Performance Benchmark to test-suite proposals.Michael Kruse2018-11-211-0/+4
| | | | llvm-svn: 347369
* [Docs] Documentation for the saturation addition and subtraction intrinsicsLeonard Chan2018-11-201-0/+200
| | | | | | Differential Revision: https://reviews.llvm.org/D54729 llvm-svn: 347334
* It's itsPaul Robinson2018-11-191-1/+1
| | | | llvm-svn: 347271
* Reverted r347092 due to the following build fails:Vyacheslav Zakharin2018-11-171-48/+1
| | | | | | | http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/8662 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/26263 llvm-svn: 347129
* Preprocessing support in tablegen.Vyacheslav Zakharin2018-11-161-1/+48
| | | | | | Differential Revision: https://reviews.llvm.org/D53840 llvm-svn: 347092
* [FNeg] Add FNeg Instruction to LangRef documentCameron McInally2018-11-161-3/+49
| | | | | | | | The FNeg IR Instruction code was added with D53877. Differential Revision: https://reviews.llvm.org/D54549 llvm-svn: 347086
* Added missing whitespace in the link.Artem Belevich2018-11-161-1/+1
| | | | llvm-svn: 347013
* [CUDA] updated CompileCudaWithLLVM.rstArtem Belevich2018-11-161-20/+21
| | | | | | Differential Revision: https://reviews.llvm.org/D54608 llvm-svn: 347007
* [AMDGPU] Update code object metadata format documentationScott Linder2018-11-151-34/+519
| | | | | | | | | | | | | | | * Add amdhsa prefix to names to allow other tools to use the metadata without collision. * Make names consistent. * Simplify structure. * Change note record ID. * Switch from YAML to MsgPack format. * Document metadata assembler directive. Patch By: t-tye (Tony Tye) Differential Revision: https://reviews.llvm.org/D53445 llvm-svn: 346992
* Mark @llvm.trap coldVedant Kumar2018-11-141-1/+1
| | | | | | | | | | | | | | | | A call to @llvm.trap can be expected to be cold (i.e. unlikely to be reached in a normal program execution). Outlining paths which unconditionally trap is an important memory saving. As the hot/cold splitting pass (imho) should not treat all noreturn calls as cold, explicitly mark @llvm.trap cold so that it can be outlined. Split out of https://reviews.llvm.org/D54244. Differential Revision: https://reviews.llvm.org/D54329 llvm-svn: 346885
* Document how to comment an actual parameter.Paul Robinson2018-11-141-0/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D54446 llvm-svn: 346861
* [FileCheck] fixing docs buildbot - use proper code-block typeFedor Sergeev2018-11-131-1/+1
| | | | llvm-svn: 346740
* [BuildingAJIT] Clang-format chapters 1 and 2.Lang Hames2018-11-131-2/+2
| | | | llvm-svn: 346727
* [BuildingAJIT] Update chapter 2 to use the ORCv2 APIs.Lang Hames2018-11-131-202/+145
| | | | llvm-svn: 346726
* [FileCheck] fixing small formatting error in docsFedor Sergeev2018-11-131-1/+1
| | | | llvm-svn: 346725
* [FileCheck] introduce CHECK-COUNT-<num> repetition directiveFedor Sergeev2018-11-131-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | In some cases it is desirable to match the same pattern repeatedly many times. Currently the only way to do it is to copy the same check pattern as many times as needed. And that gets pretty unwieldy when its more than count is big. Introducing CHECK-COUNT-<num> directive which acts like a plain CHECK directive yet matches the same pattern exactly <num> times. Extended FileCheckType to a struct to add Count there. Changed some parsing routines to handle non-fixed length of directive (all currently existing directives were fixed-length). The code is generic enough to allow future support for COUNT in more than just PlainCheck directives. See motivating example for this feature in reviews.llvm.org/D54223. Reviewed By: chandlerc, dblaikie Differential Revision: https://reviews.llvm.org/D54336 llvm-svn: 346722
* [GC docs] Update the gcroot documentation to reflect recent simplifcations ↵Philip Reames2018-11-121-90/+20
| | | | | | to GCStrategy configurability llvm-svn: 346702
* [docs][statepoints] Reformulate open issues listPhilip Reames2018-11-091-45/+63
| | | | | | Some have been partially resolved, so update that. And restructure to make it easie to find and search. llvm-svn: 346518
* [docs][statepoint] Expand a bit on problems with mixing references and raw ↵Philip Reames2018-11-091-1/+9
| | | | | | pointers since it keeps coming up in discussions llvm-svn: 346513
* [docs][statepoint] tweak a titlePhilip Reames2018-11-091-2/+2
| | | | llvm-svn: 346509
* [llvm-cov] Add lcov tracefile export format.Max Moroz2018-11-092-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | Summary: lcov tracefiles are used by various coverage reporting tools and build systems (e.g., Bazel). It is a simple text-based format to parse and more convenient to use than the JSON export format, which needs additional processing to map regions/segments back to line numbers. It's a little unfortunate that "text" format is now overloaded to refer specifically to JSON for export, but I wanted to avoid making any breaking changes to the UI of the llvm-cov tool at this time. Patch by Tony Allevato (@allevato). Reviewers: Dor1s, vsk Reviewed By: Dor1s, vsk Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D54266 llvm-svn: 346506
* [docs][statepoint] Document explicitly provided stack slotsPhilip Reames2018-11-081-0/+28
| | | | | | Functionality for this was added a while ago, though never documented or extensively tested. Document it with an explicit warning. llvm-svn: 346448
* [docs][statepoints] add a section spelling out simplifications for ↵Philip Reames2018-11-081-0/+22
| | | | | | non-relocating GCs llvm-svn: 346447
* [docs] Add some subsections to make it possible to find portions of the ↵Philip Reames2018-11-081-9/+21
| | | | | | statepoint overview llvm-svn: 346446
* [docs] Clarify ELF section naming for StackMaps and fix a typoPhilip Reames2018-11-082-4/+7
| | | | llvm-svn: 346416
* [docs] Clarify expectations for stack map sections and AOT compilersPhilip Reames2018-11-081-3/+22
| | | | llvm-svn: 346405
* AMDGPU/Docs: Add product names for Vega20Konstantin Zhuravlyov2018-11-071-5/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D54178 llvm-svn: 346354
* Add support for llvm.is.constant intrinsic (PR4898)James Y Knight2018-11-071-0/+45
| | | | | | | | | | | | | | | This adds the llvm-side support for post-inlining evaluation of the __builtin_constant_p GCC intrinsic. Also fixed SCCPSolver::visitCallSite to not blow up when seeing a call to a function where canConstantFoldTo returns true, and one of the arguments is a struct. Updated from patch initially by Janusz Sobczak. Differential Revision: https://reviews.llvm.org/D4276 llvm-svn: 346322
* Introduce bug life cycle documentation.Kristof Beyls2018-11-073-0/+150
| | | | | | | | | | | | | | | 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
* [FileCheck] Parse command-line options from FILECHECK_OPTSJoel E. Denny2018-11-061-0/+3
| | | | | | | | | | | | | | | | | This feature makes it easy to tune FileCheck diagnostic output when running the test suite via ninja, a bot, or an IDE. For example: ``` $ FILECHECK_OPTS='-color -v -dump-input-on-failure' \ LIT_FILTER='OpenMP/for_codegen.cpp' ninja check-clang \ | less -R ``` Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D53517 llvm-svn: 346272
* AMDGPU/Docs: Fix the processor tableKonstantin Zhuravlyov2018-11-061-101/+101
| | | | llvm-svn: 346263
OpenPOWER on IntegriCloud