<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Aug 19, 2017 at 12:33 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <p><br>
    </p>
    <div class="gmail-m_5672591772950106577moz-cite-prefix">On 08/19/2017 02:05 PM, Daniel Berlin
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">FWIW: to be completely concrete; from my
        perspective, the main thing we'd get out of switching is
        something that is more complete already.
        <div><br>
        </div>
        <div>past that</div>
        <div>"<span style="font-size:12.8px">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.</span>"</div>
        <div><br>
        </div>
        <div>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 :)</div>
      </div>
    </blockquote>
    <br></span>
    That's exactly my position. Good :-)<br>
    <br>
    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.<br></div></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    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. </div></blockquote><div><br></div><br class="gmail-Apple-interchange-newline"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>For non-unions, whether this is okay or not depends on your interpretation and execution of the rules.</div><div><br></div><div>If we go by the interpretation laid out by Ivan so far, it should be possible to make this work.</div><div><br></div><div>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 :)</div><div><br></div></div></div></div>