[LLVMdev] RE: Another question about GetElementPtr Instruction

Vikram S. Adve vadve at cs.uiuc.edu
Sat Sep 28 05:40:02 PDT 2002


That's correct,
	X = getElementPtr <Ty>* ptr, long 0
is a NOP.  It does exactly what you said: X = &b[0].

	X = getElementPtr <Ty>* ptr
is a NOP too.

--Vikram

-------------------------------------------------------------------------
 VIKRAM S. ADVE
 Assistant Professor                            E-MAIL: vadve at cs.uiuc.edu
 Department of Computer Science                 PHONE:  (217) 244-2016
 Univ. of Illinois at Urbana-Champaign          FAX:    (217) 244-6869
 1304 W. Springfield Ave.              WWW: http://www.cs.uiuc.edu/~vadve
 Urbana IL 61801-2987.
-------------------------------------------------------------------------


> -----Original Message-----
> From: Brian R. Gaeke [mailto:gaeke at uiuc.edu]
> Sent: Friday, September 27, 2002 10:17 PM
> To: Vikram S. Adve
> Cc: Brian R. Gaeke; llvmdev at cs.uiuc.edu
> Subject: Another question about GetElementPtr Instruction
>
>
>
> Hi,
>
> I've another question about getelementptr.  So, in the twisted
> mind of my little
> pass, I have a statement like this:
>
> %reg228-mod = getelementptr %struct.SimpleStruct* %N.1, long 0
>       ; <%struct.SimpleStruct*> [#uses=2]
>
> I'm not sure of the semantics of %a = getelementptr %b, long 0.  I want to
> think that it is some kind of weird identity (no-op), judging
> from the operand
> type and the result type that is printed out by llvm.  In this
> sense I suppose
> it is like saying a = &(b[0]) (== b). I couldn't quite make it
> out from reading
> the language reference.
>
> So I want to go ahead and transform uses of %reg228-mod by
> replacing them with
> uses of %N.1, in this example.  Is this right or am I way off?
>
> Thanks for any help,
>
> -Brian
>
>
>
> > You are correct, ubyte 2 simply means 3rd element of the
> structure.  This
> > quantity is always constant (it specifies the field number), so we could
> > have used any signed or unsigned integer type for it instead of ubyte.
> > UByte means we are limited to at most 256 structure fields but
> it also makes
> > the bytecode representation more compact.  (To remove this
> restriction, we
> > may migrate to UInt in the future and use some kind of Zipf encoding to
> > avoid increasing bytecode size in the common case.)
> >
> > There is a routine TargetData::GetIndexedOffset to convert any
> ptr + index
> > list to the actual byte  offset for a particular target machine.  See
> > llvm/include/Target/TargetData.h.
> >
> > --Vikram
> >
> >
> > > -----Original Message-----
> > > From: llvmdev-admin at cs.uiuc.edu [mailto:llvmdev-admin at cs.uiuc.edu]On
> > > Behalf Of Brian R. Gaeke
> > > Sent: Thursday, September 26, 2002 1:55 AM
> > > To: llvmdev at cs.uiuc.edu
> > > Subject: Re: [LLVMdev] question about GetElementPtr Instruction
> > >
> > >
> > >
> > > Dear LLVMdev,
> > >
> > > As far as I can tell, what the "ubyte 2" value really means is the
> > > 2+1'th member of the structure...regardless of whether that
> structure's
> > > 3rd element actually starts at (pointer to structure) +
> 3*sizeof(ubyte)
> > > or not.  So, is there any semantic connection between "ubyte" as
> > > used in structure accesses and what getelementptr actually interprets
> > > it as?  Or is it just called ubyte for fun?
> > >
> > > -"Confused in Urbana", Brian
> > >
> > > > I have a question about GetElementPtr.
> > > >
> > > > Suppose I have an GetElementPtr Instruction GI:
> > > >
> > > > %reg = getelementptr %ST* %s, uint 1, ubyte 2, ubyte 1, uint
> > > > 5, uint 13
> > >
> > > --
> > > gaeke at uiuc.edu
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> --
> gaeke at uiuc.edu
>




More information about the llvm-dev mailing list