Lines Matching refs:GC
103 use of compacting and generational GC algorithms) and it can occasionally suffer
155 The aspects of the binary interface with which LLVM's GC support is
158 * Creation of GC safepoints within code where collection is allowed to execute
183 In general, LLVM's support for GC does not include features which can be
201 IR features is specified by the selected :ref:`GC strategy description
204 Specifying GC code generation: ``gc "..."``
211 The ``gc`` function attribute is used to specify the desired GC strategy to the
217 It is the selected GC strategy which defines the exact nature of the code
218 generated to support GC. If none is found, the compiler will raise an error.
220 Specifying the GC style on a per-function basis allows LLVM to link together
225 Identifying GC roots on the stack
231 either implementation (on a per :ref:`GC strategy <plugin>` basis). Longer
251 :ref:`GC strategy <plugin>`. All calls to ``llvm.gcroot`` **must** reside
260 values representing GC references are stored in to the alloca passed to the
264 are pointers into the GC heap.
346 The use of these intrinsics is naturally optional if the target GC does not
347 require the corresponding barrier. The GC strategy used with such a collector
366 Function's selected :ref:`GC strategy <plugin>`.
382 selected :ref:`GC strategy <plugin>`.
391 Built In GC Strategies
396 The Shadow Stack GC
405 Unlike many GC algorithms which rely on a cooperative code generator to compile
421 of :ref:`more advanced GC features <collector-algos>` of LLVM in order to
461 /// Calls Visitor(root, meta) for each GC root on the stack.
468 /// @param Visitor A function to invoke for every GC root on the stack.
490 in writing an ``gcroot`` compatible GC plugin. In particular, these are the
499 The Statepoint Example GC
506 This GC provides an example of how one might use the infrastructure provided
507 by ``gc.statepoint``. This example GC is compatible with the
510 custom GC strategy around the ``gc.statepoints`` mechanisms, it is recommended
513 This GC strategy does not support read or write barriers. As a result, these
516 The stack map format generated by this GC strategy can be found in the
521 The CoreCLR GC
528 This GC leverages the ``gc.statepoint`` mechanism to support the
531 Support for this GC strategy is a work in progress. This strategy will
533 :ref:`statepoint-example GC<statepoint_example_gc>` strategy in
544 Custom GC Strategies
547 If none of the built in GC strategy descriptions met your needs above, you will
588 User code specifies which GC code generation to use with the ``gc`` function
591 To implement a GC plugin, it is necessary to subclass ``llvm::GCStrategy``,
608 // lib/MyGC/MyGC.cpp - Example LLVM GC plugin
796 The stack map consists of the location and identity of each GC root in the
848 the function. This prevents the GC's sweep phase from visiting uninitialized
854 this feature should be used by all GC plugins. It is enabled by default.
879 your GC. The best example of such a pass is the ShadowStackGC and it's
894 namespace GC {
911 NeededSafePoints = 1 << GC::Loop
912 | 1 << GC::Return
913 | 1 << GC::PreCall
914 | 1 << GC::PostCall;
927 GC::PointKind PointKind = PI->Kind;
950 of a module's assembly code. At the end of the module, the GC can compile the
972 // lib/MyGC/MyGCPrinter.cpp - Example LLVM GC printer
1019 // A compact GC layout. Emit this data structure: