<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <tt><br>
    </tt><tt>Jakob,<br>
      <br>
      I've attached a modified patch with the changes you suggested. A
      couple of comments: I will remove the emission of the second table
      when I split up the transition tables for each subtarget in
      Hexagon since those two tasks are related. Also, it was possible
      to change most of the STL containers (but not all) to LLVM
      equivalents. Let me know if it's okay to commit. I will post the
      CodeGenerator.html changes as a separate patch.<br>
      <br>
      Thanks<br>
      -Anshu<br>
    </tt><tt><br>
    </tt>
    <div class="moz-text-html" lang="x-western">
      <link rel="File-List"
href="file:///C:%5CUsers%5Cadasgupt%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml">
      <link rel="themeData"
href="file:///C:%5CUsers%5Cadasgupt%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx">
      <link rel="colorSchemeMapping"
href="file:///C:%5CUsers%5Cadasgupt%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml">
      <tt>--<br>
        Qualcomm Innovation Center, Inc is a member of Code Aurora Forum<br>
        <br>
      </tt> </div>
    <tt>
    </tt><br>
    <tt><br>
      <br>
      <br>
      <br>
      On 11/29/2011 12:22 PM, Jakob Stoklund Olesen wrote:</tt>
    <blockquote cite="mid:6F0200FC-AFFA-40EE-A66F-A6149E6862F7@2pi.dk"
      type="cite"><tt><br>
      </tt>
      <div>
        <div><tt>On Nov 29, 2011, at 7:34 AM, Anshuman Dasgupta wrote:</tt></div>
        <div><tt><br>
          </tt></div>
        <blockquote type="cite">
          <div bgcolor="#FFFFFF" text="#000000"><tt>> You are
              building CachedTable on demand. Is that really necessary?
              How much of the table is built in<br>
              > a typical run? Would it be better/faster to just
              build the whole thing up front?<br>
              <br>
              That was an interesting decision. So the reason why I
              implemented CachedTable is that currently the DFA
              generator constructs one common transition table for all
              versions (subtargets) of Hexagon. As a result, when we
              compile for a particular Hexagon subtarget, I noticed that
              only part of the transition table is typically used. I
              have plans to augment the DFA generator to create separate
              tables for each Hexagon subtarget and once I do, I will
              change this to load up the entire transition table. But
              for now CachedTable is useful.<br>
            </tt></div>
        </blockquote>
        <div><tt><br>
          </tt></div>
        <div><tt>That makes perfect sense.</tt></div>
        <div><tt><br>
          </tt></div>
        <blockquote type="cite">
          <div bgcolor="#FFFFFF" text="#000000">
            <p class="MsoNormal"><tt><span class="Apple-style-span"
                  style="font-family: monospace; font-size: 14px; ">>
                  You have 4 table lookups per DFA transition by my
                  count. It seems that 1 is enough. Can the API be
                  improved to allow that?</span></tt></p>
            <tt> </tt>
            <p class="MsoPlainText"><tt>> Could you get rid of the
                DFAStateEntryTable by renumbering your states?</tt></p>
            <tt> </tt>
            <p class="MsoPlainText"><tt>> s ->
                DFAStateEntryTable[s]</tt></p>
            <tt> </tt>
            <p class="MsoPlainText"><tt>> This would preclude the
                sparse transition matrix representation, of course.</tt></p>
            <tt> </tt>
            <p class="MsoPlainText"><tt> </tt></p>
            <tt> </tt>
            <p class="MsoPlainText"><tt>If I understand correctly, these
                two questions are related. Let me answer them together.
                I can change the code so that there is one lookup per
                transition. That was my original design. However, most
                of the table entries were invalid transitions. So, while
                running TableGen, the I/O required to emit the table
                became a bottleneck. It significantly slowed down the
                Hexagon backend build time. Therefore I moved to a
                sparse matrix representation.</tt></p>
          </div>
        </blockquote>
        <div><tt><br>
          </tt></div>
        <div><tt>OK, I actually meant CachedTable lookups. Hash table
            lookups are an order of magnitude slower than array lookups.</tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt>I assume the API is meant to be used like this:</tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt> if (DFA.canReserveResources(MI))</tt></div>
        <div><tt>   DFA.reserveResources(MI);</tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt>That's 4 hash table lookups for a valid transition. 1
            should be enough. For invalid transitions, you need two
            lookups because CachedTable is lazily built.</tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt>As for renumbering the states, since the state numbers
            aren't used for anything but indexing DFAStateEntryTable,
            you can simply replace all state numbers
            with DFAStateEntryTable[s], and you don't have to waste
            memory on the table.</tt></div>
        <div><tt><br>
          </tt></div>
        <div><tt>/jakob</tt></div>
        <div><tt><br>
          </tt></div>
      </div>
    </blockquote>
    <tt><br>
    </tt>
  </body>
</html>