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
}
-- Luc
--
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
