[llvm-dev] RFC: Resolving TBAA issues

[Hal Finkel via llvm-dev]

On 08/20/2017 12:02 PM, Daniel Berlin wrote:
>
>
>
>     I do not believe the current proposal will solve all of those
>     cases, particularly when the fields are the same type and
>     structures are compatible but they cannot overlap in C/C++ anyway.
>
> One of the threads is titled "[PATCH] D20665: Claim NoAlias if two 
> GEPs index different fields of the same struct"
>
> For example, given
> struct {
>   int arr_a[2];
>   int arr_b[2];
> };
> assume you cannot see the original allocation site.
> in llvm ir gep(arr_b,  -1) is legally an access to arr_a[1].
> You can use -1 even though it's going to be a pointer to [2 x i32].
> Thus, you can't even tell that gep(arr_a, 0) and  gep(arr_b, -1) do 
> not overlap without being able to know *something* about the layout of 
> fields in the structure you are talking about.
>
> I'd start with: It should not require tbaa to determine that loads 
> from geps that arr_a and arr_b cannot overlap.   It is true regardless 
> of the types involved.
>
> In terms of "who cares", Google definitely compiles with 
> -fno-strict-aliasing (because third party packages are still not clean 
> enough), and last i looked, Apple did the same (but i admittedly have 
> not kept up).

We definitely also have code that we compile that way as well. As it 
turns out, this is my motivation for developing the type sanitizer (so 
we have some tool that users can employ to clean up this kind of code). 
Patches have been posted for review.

>
> GCC can definitely disambiguate field accesses (through points-to and 
> otherwise) better than LLVM in a situation where strict aliasing is off.
>
> As an aside, i also can't build a sane field-sensitive points-to on 
> our current type system, because the types and structures are already 
> meaningless  (and we are busy making it weaker, too).
> I don't think we are going to want to tie field-sensitive points-to to 
> TBAA (you definitely want to be able to run the former without the 
> latter), but right now that is the only metadata you can use.

This also brings up a good point. Even if we use the same metadata for 
both type and field analysis, I don't see why we can't disable the type 
portions without disabling the field analysis (essentially by emitting 
everything as one universally-aliasing type). Maybe we should do that 
for -fno-strict-aliasing?

Thanks again,
Hal

>
> Finally, the merging of TBAA is definitely going to be more 
> conservative than the merging of field offset info: If we merge a load 
> of an int and a float, we will, IIRC, go to the nearest common 
> ancestor in TBAA.   The field offset info may actually still be 
> identical between the two, but we will lose it by creating/or going to 
> the common ancestor.
>
>
>
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/b7de83dd/attachment.html>