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

[Qin Zhao via llvm-commits]

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