<div dir="ltr"><div>I didn't initially notice the binary size. I open the X86GenAsmMatcher.inc and noticed the new classes in the table while looking at something else. This led me to investigate the history of the change which is when I found out it was not reviewed. And that it increased the table size on all targets but Hexagon with no benefit to those targets.</div><div><br></div><div>Further review indicated that this appears to be a suboptimal algorithm implementation for the Hexagon target anyway due to the linear scan. Do you have any large Hexagon asm files that you could measure parsing performance of with this linear scan vs the previous operand reordering hack you had mentioned?</div><div><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 8, 2016 at 12:03 PM, Colin LeMahieu <span dir="ltr"><<a href="mailto:colinl@codeaurora.org" target="_blank">colinl@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">colinl added a comment.<br>
<br>
For reference before the r256669 the binary size of all LLVM tools in release mode with a MinGW build was 78,331,196 and the size with the patch is 77,467,273, approximately 1%.  Is the binary size difference of the tools what spawned the investigation?<br>
<br>
Does the list have opinions on the severity of this type of issue?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D14257" rel="noreferrer" target="_blank">http://reviews.llvm.org/D14257</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">~Craig</div>
</div>