New primitive type for 32/64 compatibility?

Hello,

I was asking some questions on IRC tonight about LLVM and 32bit/64bit
compatibility. I'm sure some of these questions sound a bit naive, but
so far you guys have been wonderful at forgiving my lack of knowledge :slight_smile:

I'm interested in having one LLVM bytecode file that I can then turn
into a 32bit or 64bit ELF file that links against 32bit or 64bit ELF
shared libraries, respectively. Only care about Linux for now, to keep
things simple/sane.

Looking at the assembly manual, the width of every first class type except
pointer, bool and label is well defined. Let's say I have a C program
which calls into libfoo, like this:

{
  long num;

  ... num = .....

  foo_xyz(num);
}

In other words, in order to call this function correctly you have to know
that the width of the first parameter changes between 32bit and 64bit
hosts. Right now I don't see any way to represent this in LLVM
assembly. Playing with the web demo shows that a "long foo" is compiled
down to an int, because the demo machine is running on a 32 bit system.

To be able to deal with the case of passing long/size_t into functions,
shouldn't there be a first class type that has indeterminate width decided
only at native code generation time?

I understand that right now LLVM doesn't really abstract 32/64 bitness
away. Indulge my fantasies and pretend that this is a goal. Would
introducing a new primitive type work? How would that affect the
JIT/optimisers/implementation?

thanks -mike

Adding something like this would certainly be possible, but I'm not sure it's really appropriate. The problem is that 'long' varies in different ways on different platforms/os's, some of which make sense, and some of which do not. Also, this is a very c-centric request, I am not sure if it makes sense for other people.

While I don't think that having 'long_t' or something like that is necessarily a good idea, I do think that having an 'intptr' type could be a useful feature, with the advantage of it being a language-independent construct. I think this would capture what you're really going for, and have very simple and well-defined meaning. If other front-end people think that this would be a useful abstraction for providing portable code, and can give examples where it would be used, that would provide a lot of credibility in my mind for the feature.

The bigger problem I suspect is that you'll need to modify the LLVM C front-end, llvm-gcc, to produce these. I suspect that making it produce these will be fairly hard, as GCC's internal representation is notoriously for being not type-consistent. If you wanted to start on a project like this, that would be the place to get started.

-Chris

While I don't think that having 'long_t' or something like that is
necessarily a good idea, I do think that having an 'intptr' type could be
a useful feature, with the advantage of it being a language-independent
construct. I think this would capture what you're really going for, and
have very simple and well-defined meaning.

Yes, maybe ... what exactly is the definition of this type? On LP64
systems the width of ints and pointers are different.

                                              If other front-end people
think that this would be a useful abstraction for providing portable
code, and can give examples where it would be used, that would provide a
lot of credibility in my mind for the feature.

OK. I can't actually think of a use for it outside of C/C++ as I don't
think any other languages have types which are so loosely defined.

The bigger problem I suspect is that you'll need to modify the LLVM C
front-end, llvm-gcc, to produce these. I suspect that making it produce
these will be fairly hard, as GCC's internal representation is
notoriously for being not type-consistent. If you wanted to start on a
project like this, that would be the place to get started.

Alright. I will keep this in mind. Thanks for getting me started.

thanks -mike

intptr_t is an integer that is always the same size as the pointer, on an LP64 system, it would be 64-bits, regardless the size the C compiler thinks long, long long or int should be.

-Chris