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 On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote:> 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 > > >Sandro > >_______________________________________________ > >LLVM Developers mailing list > >LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On Mon, 18 Jun 2007, Sandro Magi wrote:> 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> On 6/18/07, Reid Spencer <rspencer at reidspencer.com> wrote: >> 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 >> >>> Sandro >>> _______________________________________________ >>> LLVM Developers mailing list >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> >>> >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
On 6/18/07, Chris Lattner <sabre at nondot.org> wrote:> On Mon, 18 Jun 2007, Sandro Magi wrote: > > 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.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