Displaying 4 results from an estimated 4 matches for "annotatedtyp".
Did you mean:
annotatedtype
2013 Nov 11
0
[LLVMdev] Improving GC intrinsics in LLVM
...nsics.
Currently the llvm.gcroot intrinsic associates a set of GC metadata with a
value, specifically a value produced by an alloca instruction. In the
proposed scheme, GC metadata would instead be associated with a *type*.
The most general approach would be to introduce a new derived type called
AnnotatedType, which is essentially a tuple consisting of (base type, id,
metadata). The base type can be any valid LLVM type, including another
AnnotatedType. The 'id' argument is an integer constant that is used to
determine what kind of annotation this is. The 'metadata' argument is a
const v...
2012 Dec 31
0
[LLVMdev] Extending GC infrastructure for roots in SSA values
...t understand it any better now. Can you
describe some examples of illegal transformations that would occur if
the current optimization passes were left unchanged?
> A different approach would be to create a new kind of derived type that
> associates metadata with an existing type. This "AnnotatedType" would be
> essentially a tuple (type, metadata), and would be constant-folded just like
> other types are. Just like the existing GC intrinsics today, there would be
> some way for a post-optimization pass to get access to all of the stack
> variables an examine the annotations o...
2012 Dec 28
5
[LLVMdev] Extending GC infrastructure for roots in SSA values
I'm working on an LLVM backend for Idris, a garbage-collected pure
functional programming language, and have experienced some frustration
that LLVM's GC support, specifically with regard to mapping roots,
operates only on allocas. This entails a lot of otherwise unnecessary
stack allocation (especially in a pure language, where in-place
mutation is rare) and imposes limitations on what
2012 Dec 30
0
[LLVMdev] Extending GC infrastructure for roots in SSA values
...e to pay an extra 4-8 bytes per Pointer type.
And second, that all of the optimization passes would have to be updated so
as to not do illegal transformations on a GC type.
A different approach would be to create a new kind of derived type that
associates metadata with an existing type. This "AnnotatedType" would be
essentially a tuple (type, metadata), and would be constant-folded just
like other types are. Just like the existing GC intrinsics today, there
would be some way for a post-optimization pass to get access to all of the
stack variables an examine the annotations on each to determine...