Displaying 6 results from an estimated 6 matches for "pairptr".
Did you mean:
dirptr
2004 Jul 21
2
[LLVMdev] GC questions.
...void *llvm_gc_read(void *ObjPtr, void **FieldPtr) {
> > return *FieldPtr;
> > }
>
> Hm, but doesn't FieldPtr need to be calculated target-specific in those
> cases?
For the field pointer, one could use the getelementptr instruction:
%pairty = { sbyte, sbyte, int* }
%pairPtr = ...
%fieldptr = getelementptr %pairty* %pairPtr, int 0, uint 2
FieldVal = llvm.gc_read(pairptr, fieldptr)
Because of the getelementptr instruction is used, we don't have the
explicit offset encoded into the bytecode file. The other advantage of
this is that when the gc_read/write intrin...
2004 Jul 21
0
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> This will work, but it would be better to take two pointers in instead of
> a pointer and offset. This allows the front-end to emit target-generic
> code instead of target-specific code (where it would have to know the
> offset to the field). To be more specific, llvm_gc_read should
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> [1] I'm kind of newbie of cvs, but I did:
> "cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm diff llvm > gcpatch"
That patch is well formed. You did exactly the right thing. :)
> Ok, a patch[1] is attached. I didn't care to coerce the offset, since I
> assume that it is an uint, but maybe I should?
2004 Jul 21
0
[LLVMdev] GC questions.
...> > > return *FieldPtr;
> > > }
> >
> > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > cases?
>
> For the field pointer, one could use the getelementptr instruction:
>
> %pairty = { sbyte, sbyte, int* }
>
> %pairPtr = ...
> %fieldptr = getelementptr %pairty* %pairPtr, int 0, uint 2
> FieldVal = llvm.gc_read(pairptr, fieldptr)
>
> Because of the getelementptr instruction is used, we don't have the
> explicit offset encoded into the bytecode file. The other advantage of
> this is that...
2009 Feb 18
2
[LLVMdev] Parametric polymorphism
...ompilation times go through the roof, and the linker
has to weed out all the duplicate instantiations.
The second problem with C++ templates is that every template
instantiation always generates completely new code, even when it
doesn't need to. Consider the following two functions:
struct PairPtr<T> { T* first, T* second };
struct Pair<T> { T first, T second };
T* getSecondPtr<T>(PairPtr<T>* pair) { return pair->second; }
T getSecond<T>(Pair<T>* pair) { return pair->second; }
The generated code for getSecondPtr() is the same for every...
2004 Jul 22
2
[LLVMdev] GC questions.
...> }
> > >
> > > Hm, but doesn't FieldPtr need to be calculated target-specific in those
> > > cases?
> >
> > For the field pointer, one could use the getelementptr instruction:
> >
> > %pairty = { sbyte, sbyte, int* }
> >
> > %pairPtr = ...
> > %fieldptr = getelementptr %pairty* %pairPtr, int 0, uint 2
> > FieldVal = llvm.gc_read(pairptr, fieldptr)
> >
> > Because of the getelementptr instruction is used, we don't have the
> > explicit offset encoded into the bytecode file. The other advant...