Displaying 9 results from an estimated 9 matches for "burmes".
Did you mean:
buries
2004 Jul 21
0
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Chris Lattner wrote:
>
> Yes, this makes a tremendous amount of sense. Do you think you could
> prepare some patches to make this happen? If you have any questions, feel
> free to ask :)
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? Hopefully I've understood
the llvm source
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
>
> Hi, I'm thinking out loud, please give me some feedback.
>
> Regarding llvm.gcread and llvm.gcwrite, wouldn't it be nicer if they are
> implemented as:
>
> llvm.gcread(sbyte** object, uint offset)
> llvm.gcwrite(sbyte* data, sbyte** object, uint offset)
>
> Where you also have the offset into the object. In
2006 Oct 02
2
[LLVMdev] Instruction descriptions question
Hi Chris,
Thanks a lot for your answer!
Chris Lattner wrote:
>> 1. Why does X86 instruction set description provide different
>> descriptions for the same instructions, which differ only in the
size
>> of operands?
>> E.g.
>>
>> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src),
>> "mov{b} {$src, $dst|$dst, $src}",
2004 Jul 21
0
[LLVMdev] GC questions.
Ok, that makes sense :).
, Tobias
On Wed, 21 Jul 2004, Chris Lattner wrote:
> On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > > 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
2004 Jul 21
2
[LLVMdev] GC questions.
On Wed, 21 Jul 2004, Tobias Nurmiranta wrote:
> > 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
2004 Jul 22
2
[LLVMdev] GC questions.
Ok, here's the new patch. (Please tell me if I shouldn't mail patches
directly on the mailing list.)
While I was editing LowerGC.cpp I made a little test (not part of this
patch, but the diff with LowerGC.cpp in cvs is attached). I've added a new
intrinsic called llvm.gcroot_value(sbyte*, sbyte*), which takes a pointer
directly instead and transforms it into an alloca. The idea is the
2006 Oct 02
0
[LLVMdev] Instruction descriptions question
On Mon, 2 Oct 2006, Roman Levenstein wrote:
>>> Wouldn't it be possible and even more clean to have just one
>>> description like (I use a pseudo-description here):
>>>
>>> def MOVrr : I<0x88, MRMDestReg, (ops (GR8|GR16|GR32) :$dst,
>>> (i8mem|i16mem|i32mem):$src),
>>> "mov{b} {$src, $dst|$dst, $src}", []>,
2006 Oct 02
0
[LLVMdev] Instruction descriptions question
On Sun, 1 Oct 2006, Roman Levenstein wrote:
> I'm trying to implement a new backend for an embedded CISC processor.
> Therefore I thought that it makes sense to take X86 target as a basis,
> to save some time.
Ok. Note that the X86 backend is one of the most complex though, because
it supports several subtargets and ABIs, which makes it more complex than
some other targets.
>
2006 Oct 01
2
[LLVMdev] Instruction descriptions question
Hi,
I'm trying to implement a new backend for an embedded CISC processor.
Therefore I thought that it makes sense to take X86 target as a basis,
to save some time.
But when I look into the X86InstrInfo.td, I have a very strong feeling
that it is one of the most complex instruction set descriptions
compared to other targets. I can imagine that this is due to the
complexity of X86's