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 >
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>
On Mon, Aug 9, 2010 at 2:43 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote:> 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. > > JoshuaThat might be your best bet. There is more architecture dependence that isn't trivial to get rid of: 1. The ABI varies from OS to OS on many platforms, and ABI details are sometimes handled by llvm-gcc/clang rather than llc. There's also at least one case where a particular named type is passed/returned differently from other types with the same structure. 2. Unions aren't really implemented in LLVM, and any front-end implementations require knowledge of the platform (which union member is the largest, the integer or the pointer?) 3. va_arg is handled specially be llvm-gcc/clang, because it's not implemented on all platforms. You can hide a lot of this in a platform dependent .bc file that you ship with your front-end, or have your front-end build for you. Support/TypeBuilder.h has some macros you might find useful for generating a Module with a platform-independent API that does the necessary typecasting for you to call platform-dependent stuff. TypeBuilder takes a compile-type C/C++ type and turns it into an llvm::Type*.
On Mon, Aug 9, 2010 at 4:08 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:> On Mon, Aug 9, 2010 at 4:02 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote: >> >> >> On Mon, Aug 9, 2010 at 1:51 PM, Kenneth Uildriks <kennethuil at gmail.com> >> wrote: >>> >>> On Mon, Aug 9, 2010 at 2:43 PM, Joshua Warner <joshuawarner32 at gmail.com> >>> wrote: >>> > 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 >>> >>> That might be your best bet. There is more architecture dependence >>> that isn't trivial to get rid of: >>> >>> 1. The ABI varies from OS to OS on many platforms, and ABI details are >>> sometimes handled by llvm-gcc/clang rather than llc. There's also at >>> least one case where a particular named type is passed/returned >>> differently from other types with the same structure. >>> 2. Unions aren't really implemented in LLVM, and any front-end >>> implementations require knowledge of the platform (which union member >>> is the largest, the integer or the pointer?) >>> 3. va_arg is handled specially be llvm-gcc/clang, because it's not >>> implemented on all platforms. >>> >>> You can hide a lot of this in a platform dependent .bc file that you >>> ship with your front-end, or have your front-end build for you. >>> Support/TypeBuilder.h has some macros you might find useful for >>> generating a Module with a platform-independent API that does the >>> necessary typecasting for you to call platform-dependent stuff. >>> TypeBuilder takes a compile-type C/C++ type and turns it into an >>> llvm::Type*. >> >> For a platform-dependent .bc file, are you suggesting something like a >> defining a i8* @mask_lower_bits(i8*), one per platform, in different .bc >> files (linked in just before final code generation)? >> Then, I would just declare that function in each module I emit, call it >> whenever appropriate, and trust llvm to inline it? ...I kind of like that >> idea. That would allow my front-end (until it invokes the optimizer, at >> least) not to worry about sizes of pointers, etc. I have no need of unions >> or va_arg, and the code I'm generating already has a layer of insulation >> between it and all external APIs anyway. >> >> Thanks! >> >> Joshua >> >> > Yes, something like that would work. I have a bunch of platform > dependent stuff I'm trying to insulate, so I'm creating a tool that > runs when building my front-end that uses the LLVM libraries to > generate a .bc file full of that stuff for me, but that might be > overill for your case. >