Hi Luc,
On 6 March 2017 at 16:43, Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
> On Tue, Mar 07, 2017 at 12:22:07AM +0800, Christopher Li wrote:
>> On Mon, Mar 6, 2017 at 11:32 PM, Dibyendu Majumdar
>> <mobile@xxxxxxxxxxxxxxx> wrote:
>> >
>> > Sparse-llvm appears to bypass the normal struct GEP in LLVM. It
>> > basically casts everything to char *, uses GEP to obtain a pointer to
>> > member, and then casts it back to member type. So this should work for
>> > structs and unions.
>>
>> That is exactly my question. I haven't understand how this by pass
>> can work in all the situation.
>>
>> >
>> > This case is more about handing pointer arithmetic correctly. Here GEP
>> > is being used as array element access and not for struct member
>> > access.
>>
>> Even using array element access, I still have some question regarding
>> the the mapping process of the array index.
>> Correct me if I am wrong, the GEP indices are express as array index.
>> So after convert to (char*) + offset, the offset will express as
>> n*(sizeof(element type)).
>> "n" is the array index.
>>
>> However, the OP_ADD instruction, the offset is byte offset value. The offset
>> part might not be align to n*(sizeof(array_elelment)). Assume we can use
>> some pack struct to get some member located not at the natural alignment offset.
>>
>> Even if the offset is at the type size alignment, shouldn't the indices express
>> as ( offset / sizeof(element type))? What do I miss?
>
> With an example:
> == C code ==
> void *foo(int *p) { return p + 5; }
>
> == linearized code ==
> foo:
> .L0:
> <entry-point>
> add.64 %r2 <- %arg1, $20
> cast.64 %r3 <- (64) %r2
> ret.64 %r3
>
> == LLVM code from sparse-llvm ==
> ; ModuleID = '<stdin>'
> source_filename = "sparse"
>
> define i8* @foo(i32* %ARG1) {
> L0:
> %0 = getelementptr i32, i32* %ARG1, inttoptr (i64 20 to i32*)
> %R3 = bitcast i32* %0 to i8*
> ret i8* %R3
> }
>
This may be the issue Chris is highlighting - above the offset should
be 5 not 20 in the LLVM code as the array type is i32* not i8*. Does
sparse always output array offsets in char*?
Regards
Dibyendu
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
