[LLVMdev] New primitive type for 32/64 compatibility?
mike at navi.cx
Fri Apr 15 17:58:49 PDT 2005
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
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:
... 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
More information about the llvm-dev