
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 14, 2020, at 08:24, Nicolai Hähnle via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi Paul,<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 12, 2020 at 5:37 PM Paul C. Anagnostopoulos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The Global ISel match table is a sequence of 64-bit entries. For the AMDGPU, there are about 261,000 entries. for the PowerPC, about 32,000. <br class="">

<br class="">

A significant amount of memory could be saved by reducing the entries to 32 bits. This would require reworking the matcher to deal with 32-bit entries, and then re-reworking some of the entries to pick up and assemble two 32-bit entries into one 64-bit integer. <br class=""></blockquote><div class=""><br class=""></div><div class="">I was thinking the same thing recently.</div><div class=""><br class=""></div><div class="">By comparison, SelectionDAG's table is even byte-based, it would be interesting to make the comparison with that as well. Going to byte granularity surely saves even more space, which is itself a performance benefit, but may also have a performance cost due to misalignment. (SelectionDAG also uses dynamic encoding length for integers in places, which seems a more dubious choice.)<br class=""></div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Nicolai</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br class="">

I won't be surprised if there are compelling reasons to keep the entries at 64 bits. I'd like to hear those reasons.<br class=""></blockquote></div></div></div></blockquote><div><br class=""></div><div>Most of the reasons boil down to not having the time needed to implement something better. There is one bit I'm aware of that snowballs a bit when using uint32_t or smaller. Labels and JumpTargets are currently absolute which allows them to be recorded in a simple lookup table during the first pass to encode on the second. JumpTargets will need to become relative (and know where they are in the table) to cope with a large ruleset and reduced range but that also means you have to start measuring distances between two points in the table. For fixed-sized commands that's not too bad but if the range drops below the minimum then you also have to go to variable length commands (or waste space on padding). That in turn means that you need to determine the encoded size of commands on the first pass (including JumpTargets which have unknown encoding until the label is seen later) so that the labels know their position for the second pass when we encode the table. We'll have to go from the two-pass approach to a relaxation one.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

_______________________________________________<br class="">

LLVM Developers mailing list<br class="">

<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">

</blockquote></div><br clear="all" class=""><br class="">-- <br class=""><div dir="ltr" class="gmail_signature">Lerne, wie die Welt wirklich ist,<br class="">aber vergiss niemals, wie sie sein sollte.</div></div>

_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>