[llvm-dev] RFC: Resolving TBAA issues

[Daniel Berlin via llvm-dev]

On Sat, Aug 19, 2017 at 12:33 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> On 08/19/2017 02:05 PM, Daniel Berlin wrote:
>
> FWIW: to be completely concrete; from my perspective, the main thing we'd
> get out of switching is something that is more complete already.
>
> past that
> "I don't want language-specific kinds of nodes in the grammar, and I
> believe that it's not necessary under some reasonable variant of this
> scheme. Maybe I'm wrong."
>
> If your position is that you'd be fine with a variant of this scheme, than
> i don't really think we disagree at all :)
>
>
> That's exactly my position. Good :-)
>
> Here's what I find most intriguing about this: In the way we'd discussed
> extending the current scheme to handle unions, we extend the current way
> that we traverse the graph such that, if there are multiple fields in one
> of the types with the same offset (i.e. a union), when we need to walk up
> the graph through all fields. While I still believe this is unlikely to be
> problematic in practice, we're now exploring many paths, and the asymptotic
> complexity doesn't thrill me.
>


>
> If I'm thinking about this correctly, this type of encoding makes dealing
> with unions much more efficient. The frontend knows the access path, and
> can encode that directly.
>


The usual problem with this, historically, is, staring at a given statement
(or even function), that the frontend doesn't always know the entire access
path. It can be trivially split over function calls, etc.  This is why the
usual solution was to walk the graph in both directions, with one of those
directions giving you "possible suffixes of this access path", and the
other giving you "possible prefixes of this access path", so you could
discover the alignment of one access path within another.

For unions,  since we already decided we are going to say, in those cases,
that the user needs to be more explicit, it shouldn't be an issue.

For non-unions, whether this is okay or not depends on your interpretation
and execution of the rules.

If we go by the interpretation laid out by Ivan so far, it should be
possible to make this work.

I would suggest one way to make sure we get what we want, if it doesn't
exist, is a fairly comprehensive set of tbaa test cases :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170819/fefd3b76/attachment.html>