[LLVMdev] Integer questions
eli.friedman at gmail.com
Fri Sep 5 15:57:23 CDT 2008
On Fri, Sep 5, 2008 at 12:42 PM, OvermindDL1 <overminddl1 at gmail.com> wrote:
> First off, most of my information about the integer representation in
> LLVM is from http://llvm.org/docs/LangRef.html#t_integer and I could
> use some things cleared up.
Okay... that's a good start :)
> First, I guess that smaller integer sizes, say, i1 (boolean) are
> stuffed into a full word size for the cpu it is compiled on (so 8bits,
> or 32 bits or whatever).
The code is compiled so that it works. :) At least hopefully; I think
there are still some bugs lurking with unusual types. CodeGen will
use a native register to do arithmetic.
> What if someone made an i4 and compiled it on 32/64 bit
> windows/nix/bsd on a standard x86 or x64 system, and they set the
> value to 15 (the max size of an unsigned i4), if it is still rounded
> up to the next nearest size when compiled (i8 or i32 or what-not),
> what if when that value has 15, but a 1 was added to it, it will be
> represented in memory at 16, or if you ignore all but the first 4 bits
> it would be zero. Is there any enforcement in the range of a given
> integer (in other words, regardless of architecture, would an i4 be
> constrained to only be 0 to 15, or is this the realm of the language
> to enforce, I would think it would be as having it at LLVM level would
> add noticeable overhead on non-machine size integers, and given that
> it would be in the realm of the language to deal with, how can the
> language be certain what values are directly appropriate for the
> architecture it is being compiled on)?
> In just a quick guess, I would say that something like an i4 would be
> compiled as if it was an i8, treated identically to an i8 in all
> circumstances, is this correct?
An i4 is a four-bit integer; it is guaranteed to act like a true i4
for all arithmetic operations. CodeGen will mask the integers
appropriately to achieve the desired behavior.
> Second, what if the specified integer size is rather large, say that
> an i512 was specified, would this cause a compile error (something
> along the lines of the specified integer size being too large to fit
> in the machine architecture), or would it rather compile in the
> necessary code to do bignum math on it (or would something like that
> be in the realm of the language designer, although having it at LLVM
> level would also make sense, after all, what best knows how to compile
> something for speed on the target system other then the compiler
> In just a quick guess, I would say that specifying an integer bit size
> too large for the machine would cause a compile error, but the docs do
> not hint at that (especially with the given example of: i1942652 a
> really big integer of over 1 million bits), is this correct?
The language and the optimizers don't have any issues with such types,
at least in theory.
Ignoring bugs, CodeGen can currently handle anything up to i128 for
all operations on most architectures; if the operations aren't
natively supported, it falls back to calling the implementation in
More information about the LLVMdev