[PATCH] D21594: [esan|cfrag] Add counters for struct array accesses

[Daniel Berlin via llvm-commits]

You are right. What will happen is it will not look like a structure field
access, and will use i8 or something so it can do the calculation.
I'll paste a clang generated example in a bit

On Fri, Jul 1, 2016, 11:13 AM Qin Zhao <zhaoqin at google.com> wrote:

> zhaoqin added a comment.
>
> In http://reviews.llvm.org/D21594#472370, @dberlin wrote:
>
> > > I do not think a negative index for struct field indexing is valid.
> >
> > >
> >
> > > >
> >
> > >
> >
> > >
> >
> > > You are incorrect :)
> >
>
>
> I see, thanks! Update CL.
>
> > >
>
> >
>
> >
>
> > FWIW, this is a common mistake.
>
> >  Please remember that LLVM level structs and GEP do not have the same
> rules
>
> >  and pretty much no relation to C-level structs.
>
> >
>
> > GEP is just an indexing operation. Unlike C, i can form pointers to
>
> >  wherever i want, and even if i mark them inbounds, your only guarantee
> is
>
> >  that they are in the object somewhere, you have no guarantee on whether
> i
>
> >  use positive or negative gep indices to generate those pointers and
> either
>
> >  way is just as valid.
>
> >  As mentioned, there are plenty of cases frontends will generate negative
>
> >  gep indices for normal source level field accesses of C-level structs.
>
>
> I understand that GEP is just an indexing operation, which I treat it like
> LEA instr in x86.
> One thing I do not understand is how the negative index would work for a
> struct type.
> For array, because we know the element size, we can use positive or
> negative indexing to calculate an address/offset from the base.
> However for struct, if the index is not within the struct field range,
> i.e., negative or too large, how does the compiler know how the
> offset/address is calculated?
> For example, if the index is -1, how does the compiler decide the first
> negative struct field size?
> I would expect the compiler will generate an error on fail to compute the
> offset.
> Will there be a default size if no field size information available for
> the out of range index?
>
>
> http://reviews.llvm.org/D21594
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160701/b10c6381/attachment.html>