[llvm-dev] RFC: Resolving TBAA issues

[Hal Finkel via llvm-dev]

On 08/17/2017 04:49 PM, Daniel Berlin via llvm-dev wrote:
>
>
>
>     For two given access sequences we can determine if the accessed
>     objects are allowed to overlap by the rules of the input
>     language.
>
>
> Sadly, this is where this becomes "unlikely to want to use to replace 
> TBAA", at least for me. It may still be a thing we want anyway.

The rules proposed by Ivan for handling C/C++ seem pretty generic. We 
generally explain our current TBAA rules by saying that they're generic 
but motivated by C/C++ rules. I could say the same thing about this 
proposed system with its proposed rules.

>
> This scheme is really an encoding of C/C++ TBAA info so it can be read 
> by LLVM and requires that *LLVM* have some set of rules that it 
> enforces about that scheme.
> But that scheme is still very language specific in how it is used.
> GCC still has something in between this and LLVM, where the language 
> rules are a bit encoded (but not as much as you have).
>
> We (and gcc) have deliberately avoided such schemes, in favor of 
> transforming the info into abstract set trees that then tag loads and 
> stores.
>
> The encoding of "struct path" tbaa, is just a way of trading space vs 
> time in that encoding.  We trade walking time for the space of 
> transitive closure, etc.

If the provided statistic of 15% holds up, maybe which way we go in this 
trade-off space doesn't matter much?

>
> None of the TBAA in LLVM really has any *real* relation to the 
> original type system rules, and that is deliberate.  I've argued for 
> years that calling it "TBAA" just badly confuses people, and i believe 
> here is a good example :)
>
> So i don't think what you've written can be used to replace TBAA.

So *if* we just take the proposed rules for C/C++ as the rules for the 
scheme in general, I'm not sure this is true. There is an isomorphism it 
seems (we could auto-upgrade even, if we'd like, by mapping the current 
offset value onto the field id of this scheme (we'd need to use a 
different root name, however, so everything would remain consistent 
under LTO)).

  -Hal

>
> However, i *do* believe it would be useful to further optimize C and 
> C++ programs in LLVM by using access paths.
>
>
>
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
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/20170817/c2fe89e3/attachment.html>