[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

On Sun, Aug 20, 2017 at 11:22 AM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> 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.
>
>
(and we're looking into using it to do just that :P)


>
> 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?
>

That actually sounds very reasonable to me, if we can make it work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170820/2ad670ee/attachment.html>