summaryrefslogtreecommitdiffstats
path: root/llvm/docs/Statepoints.rst
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [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-081-2/+2
| | | | llvm-svn: 346416
* [docs] Clarify expectations for stack map sections and AOT compilersPhilip Reames2018-11-081-3/+22
| | | | llvm-svn: 346405
* [docs] change a few code-blocks to llvm from textNuno Lopes2017-07-261-6/+6
| | | | llvm-svn: 309117
* Statepoint Docs: fix incorrect uses of it'sSanjoy Das2017-04-191-4/+6
| | | | llvm-svn: 300797
* Refresh the statepoint docs a bitPhilip Reames2017-04-191-59/+92
| | | | | | The documentation had gotten a bit stale. The revised one are by no means perfect, but I tried to remove the obvious incorrect or misleading statements. llvm-svn: 300782
* Update Bugzilla URLs in docsIsmail Donmez2017-02-171-1/+1
| | | | llvm-svn: 295432
* [docs] Fixing Sphinx warnings to unclog the buildbotRenato Golin2016-07-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Statepoint docs] Delete trailing whitespaceSanjoy Das2016-03-041-21/+21
| | | | llvm-svn: 262730
* [docs] Add a description of current problem areas to the statepoint docsPhilip Reames2016-03-031-0/+35
| | | | | | Triggered by a question on llvm-dev about status llvm-svn: 262671
* Fix some typos in the llvm docSylvestre Ledru2016-02-141-1/+1
| | | | llvm-svn: 260855
* Add a "gc-transition" operand bundleSanjoy Das2016-01-201-1/+3
| | | | | | | | | | | | | | | | | | | Summary: This adds a new kind of operand bundle to LLVM denoted by the `"gc-transition"` tag. Inputs to `"gc-transition"` operand bundle are lowered into the "transition args" section of `gc.statepoint` by `RewriteStatepointsForGC`. This removes the last bit of functionality that was unsupported in the deopt bundle based code path in `RewriteStatepointsForGC`. Reviewers: pgavlin, JosephTremoulet, reames Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D16342 llvm-svn: 258338
* [docs] Restructure description of records created by StatepointsPhilip Reames2016-01-151-12/+23
| | | | | | The previous text was hard to understand even for me and I wrote it. Hopefully the new structure makes it a bit more clear what's going on. If anyone has word smithing suggestion or clarification questions, please let me know. llvm-svn: 257847
* [docs] Update Statepoint docs to clarify format for recent changesPhilip Reames2016-01-141-6/+16
| | | | llvm-svn: 257843
* [gc.statepoint] Change gc.statepoint intrinsic's return type to token type ↵Chen Li2015-12-261-17/+17
| | | | | | | | | | | | | | instead of i32 type Summary: This patch changes gc.statepoint intrinsic's return type to token type instead of i32 type. Using token types could prevent LLVM to merge different gc.statepoint nodes into PHI nodes and cause further problems with gc relocations. The patch also changes the way on how gc.relocate and gc.result look for their corresponding gc.statepoint on unwind path. The current implementation uses the selector value extracted from a { i8*, i32 } landingpad as a hook to find the gc.statepoint, while the patch directly uses a token type landingpad (http://reviews.llvm.org/D15405) to find the gc.statepoint. Reviewers: sanjoy, JosephTremoulet, pgavlin, igor-laevsky, mjacob Subscribers: reames, mjacob, sanjoy, llvm-commits Differential Revision: http://reviews.llvm.org/D15662 llvm-svn: 256443
* Fix typos.Bruce Mitchener2015-09-121-3/+3
| | | | | | | | | | Summary: This fixes a variety of typos in docs, code and headers. Subscribers: jholewinski, sanjoy, arsenm, llvm-commits Differential Revision: http://reviews.llvm.org/D12626 llvm-svn: 247495
* [docs][Statepoints] More on base pointersPhilip Reames2015-08-261-18/+62
| | | | | | Expand the information on base pointers to include an example, the assumptions a collector is allowed to make, legal optimizations over gc.relocates, and the assumptions made by RewriteStatepointsForGC. This is the result of a recent conversation with folks from LLIC and the confusions that came to light therein. llvm-svn: 246103
* [docs][Statepoint] Add definitions for base and derived pointersPhilip Reames2015-08-261-0/+17
| | | | | | This section will be expanded over the next few days. This is just some initial content. llvm-svn: 246041
* Rename all references to old mailing lists to new lists.llvm.org address.Tanya Lattner2015-08-051-5/+5
| | | | llvm-svn: 243999
* [Statepoints] Let patchable statepoints have a symbolic call target.Sanjoy Das2015-07-281-3/+5
| | | | | | | | | | | | | | | | | | | | Summary: As added initially, statepoints required their call targets to be a constant pointer null if ``numPatchBytes`` was non-zero. This turns out to be a problem ergonomically, since there is no way to mark patchable statepoints as calling a (readable) symbolic value. This change remove the restriction of requiring ``null`` call targets for patchable statepoints, and changes PlaceSafepoints to maintain the symbolic call target through its transformation. Reviewers: reames, swaroop.sridhar Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11550 llvm-svn: 243502
* List supported architectures for StackMap section and related intrinsicsPhilip Reames2015-07-161-0/+6
| | | | | | Not having this documented led to some confusion in a recent review thread. llvm-svn: 242441
* [Statepoints][Docs] Fix a couple of out of date examples.Sanjoy Das2015-05-131-5/+5
| | | | | | Things I had missed in r237285. llvm-svn: 237290
* [Statepoints][Docs] Fix typo: change a period to a comma.Sanjoy Das2015-05-131-1/+1
| | | | llvm-svn: 237289
* [PlaceSafepoints] New attributes for patchable statepoints.Sanjoy Das2015-05-131-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch teaches the PlaceSafepoints pass about two `CallSite` function attributes: * "statepoint-id": if the string value of this attribute can be parsed as an integer, then it is propagated to the ID parameter of the statepoint created. * "statepoint-num-patch-bytes": if the string value of this attribute can be parsed as an integer, then it is propagated to the `num patch bytes` parameter of the statepoint created. This change intentionally does not assert on a malformed value for these attributes, given that they're not "official" attributes. Reviewers: reames, pgavlin Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9735 llvm-svn: 237286
* [PlaceSafepoints] Update docs for r237214.Sanjoy Das2015-05-131-4/+4
| | | | | | | Show the two new ID and NumPatchBytes fields in the PlaceSafepoint examples in Statepoints.rst to avoid confusion. llvm-svn: 237285
* [Statepoints] Support for "patchable" statepoints.Sanjoy Das2015-05-121-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change adds two new parameters to the statepoint intrinsic, `i64 id` and `i32 num_patch_bytes`. `id` gets propagated to the ID field in the generated StackMap section. If the `num_patch_bytes` is non-zero then the statepoint is lowered to `num_patch_bytes` bytes of nops instead of a call (the spill and reload code remains unchanged). A non-zero `num_patch_bytes` is useful in situations where a language runtime requires complete control over how a call is lowered. This change brings statepoints one step closer to patchpoints. With some additional work (that is not part of this patch) it should be possible to get rid of `TargetOpcode::STATEPOINT` altogether. PlaceSafepoints generates `statepoint` wrappers with `id` set to `0xABCDEF00` (the old default value for the ID reported in the stackmap) and `num_patch_bytes` set to `0`. This can be made more sophisticated later. Reviewers: reames, pgavlin, swaroop.sridhar, AndyAyers Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D9546 llvm-svn: 237214
* [Statepoints] Split the calling convention and statepoint flags operand to ↵Pat Gavlin2015-05-121-0/+6
| | | | | | | | STATEPOINT into two separate operands. Differential Revision: http://reviews.llvm.org/D9623 llvm-svn: 237166
* Fix a docs build break introduced by rL236888.Pat Gavlin2015-05-081-1/+1
| | | | llvm-svn: 236891
* Extend the statepoint intrinsic to allow statepoints to be marked as ↵Pat Gavlin2015-05-081-9/+104
| | | | | | | | | | | | | | | | | | | | | | transitions from GC-aware code to code that is not GC-aware. This changes the shape of the statepoint intrinsic from: @llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 unused, ...call args, i32 # deopt args, ...deopt args, ...gc args) to: @llvm.experimental.gc.statepoint(anyptr target, i32 # call args, i32 flags, ...call args, i32 # transition args, ...transition args, i32 # deopt args, ...deopt args, ...gc args) This extension offers the backend the opportunity to insert (somewhat) arbitrary code to manage the transition from GC-aware code to code that is not GC-aware and back. In order to support the injection of transition code, this extension wraps the STATEPOINT ISD node generated by the usual lowering lowering with two additional nodes: GC_TRANSITION_START and GC_TRANSITION_END. The transition arguments that were passed passed to the intrinsic (if any) are lowered and provided as operands to these nodes and may be used by the backend during code generation. Eventually, the lowering of the GC_TRANSITION_{START,END} nodes should be informed by the GC strategy in use for the function containing the intrinsic call; for now, these nodes are instead replaced with no-ops. Differential Revision: http://reviews.llvm.org/D9501 llvm-svn: 236888
* [GC docs] Add example IR, assembly, and stackmaps to Statepoint documentationPhilip Reames2015-02-261-19/+103
| | | | | | | | When I originally committed the statepoint docs, I left placeholders for example IR fragments. I'm finally getting around to filling those in. I also added IR fragments to illustrate the usage of the PlaceSafepoints pass while I was at it. llvm-svn: 230601
* [GC docs] Fill in description of the statepoint-example GC strategyPhilip Reames2015-02-251-0/+1
| | | | llvm-svn: 230572
* [GC] Document the recently added PlaceSafepoints and RewriteGCForStatepoints ↵Philip Reames2015-02-251-3/+90
| | | | | | passes llvm-svn: 230420
* Fix consistently wrong sphinx markupPhilip Reames2015-02-251-19/+19
| | | | | | I'd been using '' where I should have been using ``. llvm-svn: 230407
* Update the GC docs to explicitly mention both gcroot and gc.statepointPhilip Reames2015-02-251-2/+2
| | | | | | Also, fix confusing bit of the gcroot documentation that bit me personally. llvm-svn: 230405
* [GC] Sync documentation with code namingPhilip Reames2015-02-241-11/+14
| | | | | | Fixing an issue pointed out by Sean Silva. Thanks! llvm-svn: 230403
* Intrinsics: introduce llvm_any_ty aka ValueType AnyRamkumar Ramachandra2015-01-221-7/+1
| | | | | | | | | | | | | | | Specifically, gc.result benefits from this greatly. Instead of: gc.result.int.* gc.result.float.* gc.result.ptr.* ... We now have a gc.result.* that can specialize to literally any type. Differential Revision: http://reviews.llvm.org/D7020 llvm-svn: 226857
* Reformat statepoint documentation and fix a couple of typosPhilip Reames2015-01-021-87/+287
| | | | | | Patch by Ramkumar Ramachandra <artagnon@gmail.com>. llvm-svn: 225084
* Add a section to Statepoint docs mentioning shared bugzilla search and ↵Philip Reames2014-12-041-0/+4
| | | | | | standard mailing lists llvm-svn: 223374
* Minor typo and link fixes for Statepoint documentationPhilip Reames2014-12-041-5/+3
| | | | llvm-svn: 223327
* [Statepoints 4/4] Statepoint infrastructure for garbage collection: ↵Philip Reames2014-12-021-0/+209
Documentation This is the fourth and final patch in the statepoint series. It contains the documentation for the statepoint intrinsics and their usage. There's definitely still room to improve the documentation here, but I wanted to get this landed so it was available for others. There will likely be a series of small cleanup changes over the next few weeks as we work to clarify and revise the documentation. If you have comments or questions, please feel free to discuss them either in this commit thread, the original review thread, or on llvmdev. Comments are more than welcome. Reviewed by: atrick, ributzka Differential Revision: http://reviews.llvm.org/D5683 llvm-svn: 223143
OpenPOWER on IntegriCloud