[LLVMdev] size of const_ptr for array index
Alexander Poddey
alexander.poddey at gmx.net
Tue Mar 24 11:39:07 PDT 2015
Hi Christoph,
thanks a lot for the hint!
Alex
Christoph Grenz wrote:
> Hi,
>
> AFAIK GEP indices into structs always (independent of the target
> architecture) use i32 because of historical reasons [1]. I don't know for
> sure for other indices, but i64 always seems to work for anything except
> struct indices.
>
> http://llvm.org/docs/GetElementPtr.html#why-do-struct-member-indices-
always-use-i32
>
> Regards
> Christoph Grenz
>
> Am Montag, 16. März 2015, 20:44:46 schrieb Alexander Poddey:
>> Hi all,
>>
>> when e.g. accessing a global variable residing in a structure, the c++API
>> code looks like:
>>
>> std::vector<Constant*> const_ptr_183_indices;
>> const_ptr_183_indices.push_back(const_int32_172);
>> const_ptr_183_indices.push_back(const_int32_184);
>> const_ptr_183_indices.push_back(const_int64_175);
>> Constant* const_ptr_183 = ConstantExpr::getGetElementPtr(gvar_struct_foo,
>> const_ptr_183_indices);
>>
>>
>> the struct could be
>>
>> struct stest {
>> double age;
>> double darray[3];
>> }
>>
>> The indices for accessing 'age' would be
>> 0 (32bit)
>> 0 (32bit).
>>
>> For an element of the darray, one however needs
>> 0 (32bit)
>> 1 (32bit)
>> 0-2 (64bit)
>>
>> The same for indices of vectors.
>>
>> The question:
>> Can I at runtime determine (how?) which size I have to use per case?
>> I made some tests but could not figure it out.
>>
>> So for now (at my architecture) it seems hardcoding 32 bit as default,
>> and 64bit for indices (of arrays and vectors) works. But this is not
>> portable.
>>
>> Thanks
>> Alexander
>>
>> _______________________________________________
>> 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
More information about the llvm-dev
mailing list