summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [Coroutines] Part 6: Elide dynamic allocation of a coroutine frame when possibleGor Nishanov2016-08-101-31/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A particular coroutine usage pattern, where a coroutine is created, manipulated and destroyed by the same calling function, is common for coroutines implementing RAII idiom and is suitable for allocation elision optimization which avoid dynamic allocation by storing the coroutine frame as a static `alloca` in its caller. coro.free and coro.alloc intrinsics are used to indicate which code needs to be suppressed when dynamic allocation elision happens: ``` entry: %elide = call i8* @llvm.coro.alloc() %need.dyn.alloc = icmp ne i8* %elide, null br i1 %need.dyn.alloc, label %coro.begin, label %dyn.alloc dyn.alloc: %alloc = call i8* @CustomAlloc(i32 4) br label %coro.begin coro.begin: %phi = phi i8* [ %elide, %entry ], [ %alloc, %dyn.alloc ] %hdl = call i8* @llvm.coro.begin(i8* %phi, i32 0, i8* null, i8* bitcast ([2 x void (%f.frame*)*]* @f.resumers to i8*)) ``` and ``` %mem = call i8* @llvm.coro.free(i8* %hdl) %need.dyn.free = icmp ne i8* %mem, null br i1 %need.dyn.free, label %dyn.free, label %if.end dyn.free: call void @CustomFree(i8* %mem) br label %if.end if.end: ... ``` If heap allocation elision is performed, we replace coro.alloc with a static alloca on the caller frame and coro.free with null constant. Also, we need to make sure that if there are any tail calls referencing the coroutine frame, we need to remote tail call attribute, since now coroutine frame lives on the stack. Documentation and overview is here: http://llvm.org/docs/Coroutines.html. Upstreaming sequence (rough plan) 1.Add documentation. (https://reviews.llvm.org/D22603) 2.Add coroutine intrinsics. (https://reviews.llvm.org/D22659) 3.Add empty coroutine passes. (https://reviews.llvm.org/D22847) 4.Add coroutine devirtualization + tests. ab) Lower coro.resume and coro.destroy (https://reviews.llvm.org/D22998) c) Do devirtualization (https://reviews.llvm.org/D23229) 5.Add CGSCC restart trigger + tests. (https://reviews.llvm.org/D23234) 6.Add coroutine heap elision + tests. <= we are here 7.Add the rest of the logic (split into more patches) Reviewers: mehdi_amini, majnemer Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D23245 llvm-svn: 278242
* [scudo] Documentation update for Scudo, from https://reviews.llvm.org/D23332Kostya Serebryany2016-08-091-24/+51
| | | | llvm-svn: 278180
* Revert "[X86] Support the "ms-hotpatch" attribute."Charles Davis2016-08-081-19/+1
| | | | | | | | This reverts commit r278048. Something changed between the last time I built this--it takes awhile on my ridiculously slow and ancient computer--and now that broke this. llvm-svn: 278053
* [X86] Support the "ms-hotpatch" attribute.Charles Davis2016-08-081-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Based on two patches by Michael Mueller. This is a target attribute that causes a function marked with it to be emitted as "hotpatchable". This particular mechanism was originally devised by Microsoft for patching their binaries (which they are constantly updating to stay ahead of crackers, script kiddies, and other ne'er-do-wells on the Internet), but is now commonly abused by Windows programs to hook API functions. This mechanism is target-specific. For x86, a two-byte no-op instruction is emitted at the function's entry point; the entry point must be immediately preceded by 64 (32-bit) or 128 (64-bit) bytes of padding. This padding is where the patch code is written. The two byte no-op is then overwritten with a short jump into this code. The no-op is usually a `movl %edi, %edi` instruction; this is used as a magic value indicating that this is a hotpatchable function. Reviewers: majnemer, sanjoy, rnk Subscribers: dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D19908 llvm-svn: 278048
* [BuildingAJIT] Fix a couple of typos in the Chapter 3 draft.Lang Hames2016-08-081-6/+6
| | | | llvm-svn: 278033
* testing commit accessGor Nishanov2016-08-051-1/+1
| | | | llvm-svn: 277816
* [llvm-cov] Add some documentation for the -tab-size optionVedant Kumar2016-08-041-0/+5
| | | | | | Also, un-hide the cl::opt. llvm-svn: 277741
* [sanitizer] Implement a __asan_default_options() equivalent for ScudoKostya Serebryany2016-08-021-3/+26
| | | | | | | | | | | | | | Summary: Currently, the Scudo Hardened Allocator only gets its flags via the SCUDO_OPTIONS environment variable. With this patch, we offer the opportunity for programs to define their own options via __scudo_default_options() which behaves like __asan_default_options() (weak symbol). A relevant test has been added as well, and the documentation updated accordingly. I also used this patch as an opportunity to rename a few variables to comply with the LLVM naming scheme, and replaced a use of Report with dieWithMessage for consistency (and to avoid a callback). Reviewers: llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D23018 llvm-svn: 277536
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-013-32/+32
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [IR] Introduce a non-integral pointer typeSanjoy Das2016-07-281-0/+24
| | | | | | | | | | | | | | | Summary: This change adds a `ni` specifier in the `datalayout` string to denote pointers in some given address spaces as "non-integral", and adds some typing rules around these special pointers. Reviewers: majnemer, chandlerc, atrick, dberlin, eli.friedman, tstellarAMD, arsenm Subscribers: arsenm, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D22488 llvm-svn: 277085
* [coroutines] Part 3 of N: Adding Boilerplate for Coroutine PassesDavid Majnemer2016-07-281-2/+2
| | | | | | | | | | | | | This adds boilerplate code for all coroutine passes, the passes are no-ops for now. Also, a small test has been added to verify that passes execute in the expected order or not at all if coroutine support is disabled. Patch by Gor Nishanov! Differential Revision: https://reviews.llvm.org/D22847 llvm-svn: 277033
* [docs] Add sub-mod example by Chris to GitHub proposalRenato Golin2016-07-281-0/+5
| | | | llvm-svn: 277032
* fix some typos in the docSylvestre Ledru2016-07-283-3/+3
| | | | llvm-svn: 276968
* [mips] Update the link to the MIPS documentation in CompilerWriterInfo.rst.Daniel Sanders2016-07-271-1/+1
| | | | llvm-svn: 276850
* Fix Coroutines doc exampleMehdi Amini2016-07-271-1/+1
| | | | | | SSA was broken. llvm-svn: 276843
* [coroutines] Part 2 of N: Adding Coroutine IntrinsicsDavid Majnemer2016-07-271-26/+22
| | | | | | | | | | | This is the second patch in the coroutine series. It adds coroutine intrinsics and updates intrinsic cost in TargetTransformInfoImpl.h. Patch by Gor Nishanov! Differential Revision: https://reviews.llvm.org/D22659 llvm-svn: 276839
* [docs] Fix a sphinx error in llvm-cov.rstVedant Kumar2016-07-261-0/+4
| | | | | | | | | | Failing bot: http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/12025 Fix tested with `ninja docs-llvm-html`. llvm-svn: 276820
* Retry: [llvm-cov] Add support for exporting coverage data to JSONVedant Kumar2016-07-261-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | This enables users to export coverage information as portable JSON for use by analysis tools and storage in document based databases. The export sub-command is invoked just like the others: llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary The resulting JSON contains a list of files and functions. Every file object contains a list of segments, expansions, and a summary of the file's region, function, and line coverage. Every function object contains the function's name and regions. There is also a total summary for the entire object file. Changes since the initial commit (r276813): - Fixed the regexes in the tests to handle Windows filepaths. Patch by Eddie Hurtig! Differential Revision: https://reviews.llvm.org/D22651 llvm-svn: 276818
* docs: Add reference to type metadata to langref.Peter Collingbourne2016-07-261-0/+4
| | | | llvm-svn: 276817
* Revert "[llvm-cov] Add support for exporting coverage data to JSON"Vedant Kumar2016-07-261-29/+0
| | | | | | | | | This reverts commit r276813. The Windows bots are complaining about some of the filename regexes in the tests: http://bb.pgr.jp/builders/ninja-clang-i686-msc19-R/builds/5299 llvm-svn: 276816
* [llvm-cov] Add support for exporting coverage data to JSONVedant Kumar2016-07-261-0/+29
| | | | | | | | | | | | | | | | | | | | This enables users to export coverage information as portable JSON for use by analysis tools and storage in document based databases. The export sub-command is invoked just like the others: llvm-cov export -instr-profile path/to/foo.profdata path/to/foo.binary The resulting JSON contains a list of files and functions. Every file object contains a list of segments, expansions, and a summary of the file's region, function, and line coverage. Every function object contains the function's name and regions. There is also a total summary for the entire object file. Patch by Eddie Hurtig! Differential Revision: https://reviews.llvm.org/D22651 llvm-svn: 276813
* Fix docs/Coroutines.rst syntax highlighting on LinuxSanjoy Das2016-07-261-5/+5
| | | | | | | | | | | | | Summary: s/code-block:: C++/code-block:: c++ in docs/Coroutines.rst . Patch by Gor Nishanov! Edited by Sanjoy to fix a missing s/C/c/. Reviewers: sanjoy, rengolin Differential Revision: https://reviews.llvm.org/D22832 llvm-svn: 276806
* Add link to the Hexagon documentationKrzysztof Parzyszek2016-07-261-0/+5
| | | | llvm-svn: 276788
* [lit] Document the 'available_features' member of the config object.Daniel Sanders2016-07-261-0/+3
| | | | llvm-svn: 276744
* Change some more llvm highlighting instances to be text instead. It seems ↵Aaron Ballman2016-07-231-9/+9
| | | | | | | | that Pygment does not handle "token" or "none" yet, and this caused the documentation bot to go red. Patch by Gor Nishanov. llvm-svn: 276532
* Switching the highlighting from llvm to none in an attempt to appease the ↵Aaron Ballman2016-07-231-1/+1
| | | | | | build bot (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11984/steps/docs-llvm-html/logs/stdio). llvm-svn: 276531
* Removes a warning about duplicate label named _strings from CommandLine.rst.Aaron Ballman2016-07-231-1/+1
| | | | llvm-svn: 276530
* [coroutines] Part 1 of N: DocumentationDavid Majnemer2016-07-232-0/+1222
| | | | | | | | | | | 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
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-221-2/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: apilipenko, reames Subscribers: llvm-commits llvm-svn: 276447
* [docs] Move GitHub to GitHubSubModRenato Golin2016-07-212-5/+5
| | | | | | | | 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
* Revert "Invariant start/end intrinsics overloaded for address space"Anna Thomas2016-07-211-4/+2
| | | | | | This reverts commit r276316. llvm-svn: 276320
* Invariant start/end intrinsics overloaded for address spaceAnna Thomas2016-07-211-2/+4
| | | | | | | | | | | | | | | | | | | | | Summary: The llvm.invariant.start and llvm.invariant.end intrinsics currently support specifying invariant memory objects only in the default address space. With this change, these intrinsics are overloaded for any adddress space for memory objects and we can use these llvm invariant intrinsics in non-default address spaces. Example: llvm.invariant.start.p1i8(i64 4, i8 addrspace(1)* %ptr) This overloaded intrinsic is needed for representing final or invariant memory in managed languages. Reviewers: tstellarAMD, reames, apilipenko Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D22519 llvm-svn: 276316
* Adding RELEASE_TESTERS.TXTRenato Golin2016-07-211-0/+3
| | | | llvm-svn: 276302
* [docs] Update release docsRenato Golin2016-07-211-151/+91
| | | | llvm-svn: 276264
* [docs] Fixing Sphinx warnings to unclog the buildbotRenato Golin2016-07-2022-184/+182
| | | | | | | | | | | | | | | | | | | | | | | Lots of blocks had "llvm" or "nasm" syntax types but either weren't following the syntax, or the syntax has changed (and sphinx hasn't keep up) or the type doesn't even exist (nasm?). Other documents had :options: what were invalid. I only removed those that had warnings, and left the ones that didn't, in order to follow the principle of least surprise. This is like this for ages, but the buildbot is now failing on errors. It may take a while to upgrade the buildbot's sphinx, if that's even possible, but that shouldn't stop us from getting docs updates (which seem down for quite a while). Also, we're not losing any syntax highlight, since when it doesn't parse, it doesn't colour. Ie. those blocks are not being highlighted anyway. I'm trying to get all docs in one go, so that it's easy to revert later if we do fix, or at least easy to know what's to fix. llvm-svn: 276109
* [docs] fix cmake code-block warningRenato Golin2016-07-201-4/+4
| | | | | | | This will unblock the llvm-sphinx-buildbot, which is currently failing due to a warning being treated as error. llvm-svn: 276100
* [docs] Add proposals to index fileRenato Golin2016-07-201-0/+19
| | | | llvm-svn: 276099
* [docs] GitHub Proposal for LLVMRenato Golin2016-07-201-0/+268
| | | | | | | | | | | | | | | | | | | | This document was crafted from the various (320+) emails between 2nd June and 20th July regarding the move to GitHub. It tried to consolidate every issue that was raised and every solution that was presented to have a GitHub repository with sub-modules. It *does not* try to argue whether sub-modules are better or worse than any other Git solution, nor if Git is better than any other VCS, nor if GitHub is better than any other free code hosting service. This is just the final conclusions of 48 days and 320 emails (plus a lot of IRC discussions) on the LLVM community. This document will be presented at the survey that the foundation will setup for us to decide if we move to this solution or not. It reflects what was discussed on the lists, but it's not authoritative. If something is not clear enough, please refer to the mailing list discussions (hint: search for "GitHub"). Review: https://reviews.llvm.org/D22463 llvm-svn: 276097
* Fixing a few places in this doc which look like obvious typos.Yunzhong Gao2016-07-201-4/+5
| | | | llvm-svn: 276070
* This code block breaks the docs build ↵Aaron Ballman2016-07-191-3/+3
| | | | | | (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11925/steps/docs-llvm-html/logs/stdio). Setting the code highlighting to none instead of llvm. llvm-svn: 276060
* This code block breaks the docs build ↵Aaron Ballman2016-07-191-2/+2
| | | | | | (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11921/steps/docs-llvm-html/logs/stdio). Setting the code highlighting to none instead of llvm to hopefully get the bot stumbling back towards green. llvm-svn: 276018
* This code block breaks the docs build ↵Aaron Ballman2016-07-191-1/+1
| | | | | | (http://lab.llvm.org:8011/builders/llvm-sphinx-docs/builds/11920/steps/docs-llvm-html/logs/stdio), but I cannot see anything immediately wrong with it and cannot reproduce the diagnostic locally. Setting the code highlighting to none instead of nasm to hopefully get the bot stumbling back towards green. llvm-svn: 275998
* Retry: [llvm-profdata] Speed up merging by using a thread poolVedant Kumar2016-07-191-0/+5
| | | | | | | | | | | | | | | | | | | | | Add a "-j" option to llvm-profdata to control the number of threads used. Auto-detect NumThreads when it isn't specified, and avoid spawning threads when they wouldn't be beneficial. I tested this patch using a raw profile produced by clang (147MB). Here is the time taken to merge 4 copies together on my laptop: No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total Changes since the initial commit: - When handling odd-length inputs, call ThreadPool::wait() before merging the last profile. Should fix a race/off-by-one (see r275937). Differential Revision: https://reviews.llvm.org/D22438 llvm-svn: 275938
* Revert "[llvm-profdata] Speed up merging by using a thread pool"Vedant Kumar2016-07-191-5/+0
| | | | | | | | | | | This reverts commit r275921. It broke the ppc64be bot: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/3537 I'm not sure why it broke, but based on the output, it looks like an off-by-one (one profile left un-merged). llvm-svn: 275937
* [Kaleidoscope][BuildingAJIT] More work on the text for Chapter 3.Lang Hames2016-07-191-33/+46
| | | | | | | | | | | Add an overview of stubs and compile callbacks before the discussion of the source changes. -- This line, and those below, will be ignored-- M docs/tutorial/BuildingAJIT3.rst llvm-svn: 275933
* [llvm-profdata] Speed up merging by using a thread poolVedant Kumar2016-07-181-0/+5
| | | | | | | | | | | | | | | | Add a "-j" option to llvm-profdata to control the number of threads used. Auto-detect NumThreads when it isn't specified, and avoid spawning threads when they wouldn't be beneficial. I tested this patch using a raw profile produced by clang (147MB). Here is the time taken to merge 4 copies together on my laptop: No thread pool: 112.87s user 5.92s system 97% cpu 2:01.08 total With 2 threads: 134.99s user 26.54s system 164% cpu 1:33.31 total Differential Revision: https://reviews.llvm.org/D22438 llvm-svn: 275921
* Trunk release notes now refer to 4.0.0Hans Wennborg2016-07-181-85/+11
| | | | llvm-svn: 275842
* Bump the trunk version to 4.0.0svn.Hans Wennborg2016-07-182-4/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D21821 llvm-svn: 275827
* Fixed errors in docs.Alexander Kornienko2016-07-181-0/+3
| | | | llvm-svn: 275789
* bugpoint: add flag -verbose-errorsSebastian Pop2016-07-151-0/+8
| | | | | | | | | | | | The default behavior of bugpoint is to print "<crash>" when it finds a reduced test that crashes compilation. With this flag we now can see the output of the crashing program. This is useful to make sure it is the same error being tracked down and not a different error that happens to crash the compiler as well. Differential Revision: https://reviews.llvm.org/D22411 llvm-svn: 275646
OpenPOWER on IntegriCloud