[llvm-dev] RFC: Representing unions in TBAA

[Daniel Berlin via llvm-dev]

On Sun, Mar 19, 2017 at 2:55 PM, Steven Perron <perrons at ca.ibm.com> wrote:

> Hello all,
>
> I started implementing Daniel's idea, and I noticed a couple things that
> should be addressed.
>
> 1) The root node:  Clang currently generates a root node named "Simple C++
> TBAA" (or something similar).  From the comments it looks like this is used
> to determine whether or not two TBAA DAGs from different translation units
> can be merged into a single on during LTO.  I plan on keeping that node,
> but making it the universal "sink" node as before.  This means that, in the
> new interpretation of the graph, it will be a child of everything instead
> of a parent of everything.  However, since it is still the sink, it can
> still work in LTO as before.  This is just a guess, because I have not
> looked at the code that uses this.
>
> 2) char: Daniel suggested omitting the aliasing for because we know it
> aliases everything.
>

Not quite. I suggested not explicitly representing it as a node.


> The problem with this is that llvm does not alias the current "omnipotent
> char" to everything.  As is pointed out in the comments:
>
>   // Define the root of the tree for user-accessible memory. C and
> C++
>   // give special powers to char and certain similar types.
> However,
>   // these special powers only cover user-accessible memory, and
> doesn't
>   // include things like vtables.
>

Sure.


>
> Is there another option on how to handle vtables?  If not, we may need to
> add a node for "omnipotent char", which will have lots of children.  This
> will make precomputing the transitive closure particularly important.
>

You don't need an actual node, just a single bit saying whether it is has
"aliases anything" as a child.
If so, it is equivalent to aliases anything, and you do not need to store
any more children.

See, e.g., what gcc does for "has_zero_child"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170319/9525cea3/attachment.html>