llvm dev - Apr 2005 - [LLVMdev] 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 :)

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

On Sat, 16 Apr 2005, Mike Hearn wrote:
> 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?
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

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

On Sat, 16 Apr 2005 10:38:10 -0500, Chris Lattner wrote:
> 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