[LLVMdev] New primitive type for 32/64 compatibility?

[Mike Hearn]

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