On Wed, Nov 11, 2009 at 2:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote:> Kenneth Uildriks wrote: >> >> On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote: >>> >>> In my case, I've been attempting to build a target-neutral frontend. In >>> my >>> tool chain, the target is specified at link time, not at compile time. >>> Among >>> other things, that means that the same IR file can be used for multiple >>> targets. >> >> That's the direction I'm going in too. >> >>> What strikes me is how tantalizingly close LLVM comes to being able to do >>> this. I am surprised, for example, that I can general all of the DWARF >>> debugging structures without ever having to choose a target machine. Most >>> things can be done quite easily without knowing the exact size of a >>> pointer. >>> When it comes to being able to "generate once, run anywhere", LLVM is >>> like >>> 99.5% of the way there. Which makes that last remaining .5% particularly >>> vexing. >>> >>> There's only a tiny handful of fairly esoteric cases which require >>> selecting >>> a target before you generate IR. Unfortunately, the "pointer the same >>> size >>> as an int" is one of these rare cases - it is something that is very >>> painful to try and work around. (A similar esoteric use case is: "which >>> of >>> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the >>> union >>> problem.) >> >> I'm willing to spend some time on adding intp to LLVM... my >> front-end's standard libraries would be cleaner and more portable that >> way. > > Sorry, but I'm still opposed. From your description of 'intp' it sounds like > it's a strict subset of pointers. You can't sext it, zext it or trunc it, > like you can with integers. You can bitcast it, but only to another pointer.You can do integer arithmetic & bitwise operations with it. You can convert it to other types of integers, although you wouldn't be able to tell whether you were truncating or zexting them at IR-generation time (at least not without target data). You can create literal values of intp type. You can, of course, safely convert it to/from a pointer. intp is an integer, not a pointer. It's sized the same as a pointer, so you can use it as a pointer offset, a size parameter, or something along those lines, without having to know how big a pointer.> > The use case you mentioned was that some native system APIs want integers > that are the same size as pointers. So why not just declare those arguments > or fields with a pointer type in LLVM? Then you've got a field with the > right size.But not necessarily the right alignment. Some platforms align pointers differently from ints.
Kenneth Uildriks wrote:> On Wed, Nov 11, 2009 at 2:10 PM, Nick Lewycky <nicholas at mxc.ca> wrote: >> Kenneth Uildriks wrote: >>> On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote: >>>> In my case, I've been attempting to build a target-neutral frontend. In >>>> my >>>> tool chain, the target is specified at link time, not at compile time. >>>> Among >>>> other things, that means that the same IR file can be used for multiple >>>> targets. >>> That's the direction I'm going in too. >>> >>>> What strikes me is how tantalizingly close LLVM comes to being able to do >>>> this. I am surprised, for example, that I can general all of the DWARF >>>> debugging structures without ever having to choose a target machine. Most >>>> things can be done quite easily without knowing the exact size of a >>>> pointer. >>>> When it comes to being able to "generate once, run anywhere", LLVM is >>>> like >>>> 99.5% of the way there. Which makes that last remaining .5% particularly >>>> vexing. >>>> >>>> There's only a tiny handful of fairly esoteric cases which require >>>> selecting >>>> a target before you generate IR. Unfortunately, the "pointer the same >>>> size >>>> as an int" is one of these rare cases - it is something that is very >>>> painful to try and work around. (A similar esoteric use case is: "which >>>> of >>>> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the >>>> union >>>> problem.) >>> I'm willing to spend some time on adding intp to LLVM... my >>> front-end's standard libraries would be cleaner and more portable that >>> way. >> Sorry, but I'm still opposed. From your description of 'intp' it sounds like >> it's a strict subset of pointers. You can't sext it, zext it or trunc it, >> like you can with integers. You can bitcast it, but only to another pointer. > > You can do integer arithmetic & bitwise operations with it. You can > convert it to other types of integers, although you wouldn't be able > to tell whether you were truncating or zexting them at IR-generation > time (at least not without target data). You can create literal > values of intp type. You can, of course, safely convert it to/from a > pointer.I'd be happy to permit arithmetic and bitwise operations on pointers. (I thought we already did. We don't.) You still can't create literal values with it (besides null) because you don't know whether your constant will fit. Or rather, what you get is exactly what the inttoptr instruction already gives you.> intp is an integer, not a pointer. It's sized the same as a pointer, > so you can use it as a pointer offset, a size parameter, or something > along those lines, without having to know how big a pointer. > >> The use case you mentioned was that some native system APIs want integers >> that are the same size as pointers. So why not just declare those arguments >> or fields with a pointer type in LLVM? Then you've got a field with the >> right size. > > But not necessarily the right alignment. Some platforms align > pointers differently from ints.Within a structure or array you mean? Or do you mean that some platforms pass pointers and integers differently as function arguments? Nick
On Wed, Nov 11, 2009 at 2:46 PM, Nick Lewycky <nicholas at mxc.ca> wrote:> I'd be happy to permit arithmetic and bitwise operations on pointers. (I > thought we already did. We don't.)That would be very helpful too.> > You still can't create literal values with it (besides null) because you > don't know whether your constant will fit. Or rather, what you get is > exactly what the inttoptr instruction already gives you.> Within a structure or array you mean? Or do you mean that some platforms > pass pointers and integers differently as function arguments? > > Nick >I mean within a structure or array. I don't know whether any platforms would pass them any differently as function arguments, but I do know that the "default" data layout (which I believe is the Sparc data layout) aligns int32's on 32-bit boundaries and 32-bit pointers on 64-bit boundaries.