[LLVMdev] llvm "iword" type

Joshua Warner joshuawarner32 at gmail.com
Mon Aug 9 12:43:30 PDT 2010


I looked through the "intp" thread.

I don't really want to start that argument up again, but my immediate
thought would be to create a new class of "picked-by-the-target" integer
types (equivelents of size_t, intptr_t, etc...), and two new instructions,
zcast and scast, which are only valid in the context of casting to / from
integer types of unknown sizes.  To begin with, most passes could probably
ignore (or otherwise pass pass over) these instructions.  The resolution of
these types would only happen in the legalize phase in the SelectionDAG.

Just my two cents...

For now, I'll settle for a little architecture dependence in my front-end.

Joshua

On Mon, Aug 9, 2010 at 1:14 PM, Kenneth Uildriks <kennethuil at gmail.com>wrote:

> That and the possibility of differently sized pointers made me
> hesitate to dive into implementing this.  I guess nailing it down to
> be the platform equivalent of size_t would be sensible here.
>
> On Mon, Aug 9, 2010 at 1:37 PM, Eugene Toder <eltoder at gmail.com> wrote:
> > Small nitpick: size_t is not guaranteed to be large enough to hold a
> > pointer (only an array index, which can be less; though such platforms
> > are pretty exotic now). [u]intptr_t are the types.
> >
> > Eugene
> >
> > On Mon, Aug 9, 2010 at 5:44 PM, Joshua Warner <joshuawarner32 at gmail.com>
> wrote:
> >> Hi,
> >>
> >> I'm generating some LLVM IR that has to mask out the lower bits two bits
> of
> >> a certain pointers.  I expect this should be done like so (on a 32-bit
> >> architecture)
> >>
> >> ...
> >> %classPointer = ...
> >> %classPointer1 = ptrtoint i8** %classPointer to i32
> >> %classPointer2 = and i32 -4, %classPointer1
> >> %realClassPointer = inttoptr i32 %classPointer2 to i8**
> >> ...
> >>
> >> Ideally, I'd like to generate completely architecture-independent code,
> >> which brings me to my question: Does LLVM have some sort of
> >> i<target_ptr_size> type that I can cast to to do this masking (like
> size_t
> >> in C), instead of generating different LLVM IR for 32- and 64- bit
> >> architectures?
> >>
> >> Thanks,
> >>
> >> Joshua
> >>
> >>
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100809/19e42cda/attachment.html>


More information about the llvm-dev mailing list