<div dir="auto">I believe the code in SelectionDAGISel.cpp that consumes the table caches the outer SwitchOpcode in a map.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 13, 2020 at 6:55 AM Paul C. Anagnostopoulos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Would it make sense for TableGen to generate the outer OPC_SwitchOpcode offset table?<br>
<br>
<br>
At 11/13/2020 07:53 AM, Nicolai Hähnle wrote:<br>
>That said, if we are seriously thinking about the performance of the byte code, perhaps some of these opcodes should be reconsidered at a higher level anyway.<br>
><br>
>For example: The overall bytecode always begins with an OPC_SwitchOpcode implemented as a linear list of cases, often hundreds of them (depending on the target). A binary search over a jump table would be *much* better for those.<br>
><br>
>Cheers,<br>
>Nicolai<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div>