Where does the storage for large bit width integers come from? Are
very large numbers heap allocated?
Sandro
Sandro Magi wrote:
Where does the storage for large bit width integers come from? Are
very large numbers heap allocated?
The ConstantInt class stores integer values. Large or not they are stored using an APInt object. APInt (lib/Support/APInt.cpp) uses an array of uint64_t if more than two are needed or an inline uint64_t in the APInt object. So, yes, they are heap allocated. This is for compile time constants. At run time, the back ends don't support anything over 128bits (currently), except lli in interpreter mode. The interpreter uses APInt instances to compute all integer operations (including very large numbers).
Reid
Ok, so if I needed very precise control over the allocation of memory,
then I should avoid using integers with bit widths larger than 64 bits
(or perhaps 128)? Is there a hard rule for an integer being stack
allocated, ie. one that doesn't depend on the current implementation
details?
Sandro
They are stored inline in whatever memory they are already embedded into.
-Chris
Actually, the native code generators and the CBE only support "normal" sized integers: 1,8,16,32,64,128 right now. We don't support small strange things like i37. Patches to improve this are welcome though 
-Chris
Ok, so if I needed very precise control over the allocation of memory,
then I should avoid using integers with bit widths larger than 64 bits
(or perhaps 128)? Is there a hard rule for an integer being stack
allocated, ie. one that doesn't depend on the current implementation
details?
In the generated code, or in the compiler itself? Reid is talking about how the compiler itself is implemented, I was describing how the generated code works.
-Chris
Generated code. So the memory used for the integer at program runtime
is inlined into the allocation point then? So if I define a local
variable of type 'i1024', it will allocate a block of 1024 bits on the
stack, if I define a struct with an i1024, it will be in the struct
itself, etc.
Is there anyone working on complete support for this in the code generators?
Sandro
Generated code. So the memory used for the integer at program runtime
is inlined into the allocation point then? So if I define a local
variable of type 'i1024', it will allocate a block of 1024 bits on the
stack, if I define a struct with an i1024, it will be in the struct
itself, etc.
Yes, exactly.
Is there anyone working on complete support for this in the code generators?
Nope, not that I know of.
-Chris
Chris Lattner wrote:
Generated code. So the memory used for the integer at program runtime
is inlined into the allocation point then? So if I define a local
variable of type 'i1024', it will allocate a block of 1024 bits on the
stack, if I define a struct with an i1024, it will be in the struct
itself, etc.
Yes, exactly.
Unless something has changed recently, both of these i1024 examples will generate an assertion in the SelectionDAG somewhere. You basically can't go past 128 in code gen right now, AFAIK.
Right, it was just a conceptual example to make sure I understood.
Thanks everyone!
Sandro