llvm.org GIT mirror llvm / 05d6709
Doc updates/edits, contributed by Terence Parr! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@50205 91177308-0d34-0410-b5e6-96231b3b80d8 Chris Lattner 11 years ago
2 changed file(s) with 19 addition(s) and 19 deletion(s). Raw diff Collapse all Expand all
150150
151151
152152

LLVM's intermediate representation provides garbage

153 collection intrinsics which offer support for a broad class of
153 collection intrinsics that offer support for a broad class of
154154 collector models. For instance, the intrinsics permit:

155155
156156
279279
280280
281281
282

The SemiSpace runtime implements with the suggested

283 runtime interface and is compatible the ShadowStack backend.

282

The SemiSpace runtime implements the suggested

283 runtime interface and is compatible with the ShadowStack backend.

284284
285285

SemiSpace is a very simple copying collector. When it starts up, it

286286 allocates two blocks of memory for the heap. It uses a simple bump-pointer
320320
321321
322322
323 Core support
323 Core support
324324
325325
326326
350350
351351
352352

The gc function attribute is used to specify the desired collector

353 algorithm to the compiler. It is equivalent to specify the collector name
353 algorithm to the compiler. It is equivalent to specifying the collector name
354354 programmatically using the setCollector method of
355355 Function.

356356
357357

Specifying the collector on a per-function basis allows LLVM to link together

358 programs which use different garbage collection algorithms.

358 programs that use different garbage collection algorithms.

359359
360360
361361
371371
372372
373373

The llvm.gcroot intrinsic is used to inform LLVM of a pointer

374 variable on the stack. The first argument must be an alloca instruction
374 variable on the stack. The first argument must be a value referring to an alloca instruction
375375 or a bitcast of an alloca. The second contains a pointer to metadata that
376376 should be associated with the pointer, and must be a constant or global
377377 value address. If your target collector uses tags, use a null pointer for
398398 ;; Tell LLVM that the stack space is a stack root.
399399 ;; Java has type-tags on objects, so we pass null as metadata.
400400 %tmp = bitcast %Object** %X to i8**
401 call void %llvm.gcroot(%i8** %X, i8* null)
401 call void %llvm.gcroot(i8** %X, i8* null)
402402 ...
403403
404404 ;; "CodeBlock" is the block corresponding to the start
438438 for completeness. In this snippet, %object is the object pointer, and
439439 %derived is the derived pointer:

440440
441
                  
                
442 > ;; An array type.
441

                  
                
442 ;; An array type.
443443 %class.Array = type { %class.Object, i32, [0 x %class.Object*] }
444 ...
444 ...
445445
446446 ;; Load the object pointer from a gcroot.
447447 %object = load %class.Array** %object_addr
448448
449449 ;; Compute the derived pointer.
450 %derived = getelementptr %obj, i32 0, i32 2, i32 %n
450 %derived = getelementptr %object, i32 0, i32 2, i32 %n
451451
452452
453453
593593 generator that iterates through all of the GC roots on the stack, calling the
594594 specified function pointer with each record. For each GC root, the address of
595595 the pointer and the meta-data (from the
596 href="#roots">llvm.gcroot intrinsic) are provided.
596 href="#gcroot">llvm.gcroot intrinsic) are provided.
597597

598598
599599
13281328 llvm_gc_collect functions. To do this, it will
13291329 probably have to trace through the roots
13301330 from the stack and understand the GC descriptors
1331 for heap objects. Luckily, there are some example
1331 for heap objects. Luckily, there are some example
13321332 implementations available.
13331333

13341334
13651365

The LLVM garbage collectors are capable of supporting all of these styles of

13661366 language, including ones that mix various implementations. To do this, it
13671367 allows the source-language to associate meta-data with the
1368 href="#roots">stack roots, and the heap tracing routines can propagate the
1368 href="#gcroot">stack roots, and the heap tracing routines can propagate the
13691369 information. In addition, LLVM allows the front-end to extract GC information
13701370 in any form from a specific object pointer (this supports situations #1 and #3).
13711371

30193019 'getelementptr' instruction is used to index down through the type
30203020 levels of a structure or to a specific index in an array. When indexing into a
30213021 structure, only i32 integer constants are allowed. When indexing
3022 into an array or pointer, only integers of 32 or 64 bits are allowed, and will
3023 be sign extended to 64-bit values.

3022 into an array or pointer, only integers of 32 or 64 bits are allowed; 32-bit
3023 values will be sign extended to 64-bits if required.

30243024
30253025

For example, let's consider a C code fragment and how it gets

30263026 compiled to LLVM:

30953095
30963096

Note that it is undefined to access an array out of bounds: array and

30973097 pointer indexes must always be within the defined bounds of the array type.
3098 The one exception for this rules is zero length arrays. These arrays are
3098 The one exception for this rule is zero length arrays. These arrays are
30993099 defined to be accessible as variable length arrays, which requires access
31003100 beyond the zero'th element.

31013101
42064206
42074207
Semantics:
42084208
4209

At runtime, a call to this intrinsics stores a null pointer into the "ptrloc"

4209

At runtime, a call to this intrinsic stores a null pointer into the "ptrloc"

42104210 location. At compile-time, the code generator generates information to allow
42114211 the runtime to find the pointer at GC safe points. The 'llvm.gcroot'
42124212 intrinsic may only be used in a function which specifies a GC