<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 29, 2011, at 7:34 AM, Anshuman Dasgupta wrote:</div><div><br></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><br></div><div>That makes perfect sense.</div><div><br></div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000"><p class="MsoNormal"><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></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><br></div><div>OK, I actually meant CachedTable lookups. Hash table lookups are an order of magnitude slower than array lookups.</div><div><br></div><div>I assume the API is meant to be used like this:</div><div><br></div><div> if (DFA.canReserveResources(MI))</div><div> DFA.reserveResources(MI);</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>/jakob</div><div><br></div></div></body></html>