<p dir="ltr"><br>
>  <br>
> However, you have a worse situation - not every field access is going to look like an access through a structure type ;)<br>
><br>
> Clang will happily generate code like this:<br>
>   %20 = load %struct.A*, %struct.A** %3, align 8<br>
>   %21 = bitcast %struct.A* %20 to i8*<br>
>   %22 = getelementptr inbounds i8, i8* %21, i64 %19<br>
><br>
> ....<br>
></p>
<p dir="ltr">I totally agree.<br>
There are many more cases that we might not catch. We just use gep instructions to approximate the struct field accesses. One gep instruction may means 0 or many field accesses. I just hope that the collected data would give us a good enough estimation for optimization.</p>
<p dir="ltr">>><br>
>> $ /usr/local/google/home/zhaoqin/Workspace/LLVM/builds/build_x64_rel.git/./bin/opt < /usr/local/google/home/zhaoqin/Workspace/LLVM/llvm.git/test/Instrumentation/EfficiencySanitizer/struct_field_gep.ll -esan -esan-cache-frag -S<br>
>> /usr/local/google/home/zhaoqin/Workspace/LLVM/builds/build_x64_rel.git/./bin/opt: <stdin>:28:50: error: invalid getelementptr indices<br>
>><br>
>>   %arrayidx = getelementptr inbounds %struct.ST, %struct.ST* %s, i64 0, i32 -1<br>
>>                                                                                  ^<br>
>><br>
>><br>
>> <a href="http://reviews.llvm.org/D21594">http://reviews.llvm.org/D21594</a><br>
>><br>
>><br>
>><br>
><br>
</p>