[LLVMdev] Arbitrary bit width integers

Chris Lattner sabre at nondot.org
Mon Jun 18 13:10:37 PDT 2007


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/



More information about the llvm-dev mailing list