<div dir="ltr"><div><div>Changes to x86 LSR can lead to surprising perf outcomes. Test any changes carefully across multiple uarches.<br> <br>I added a small bit to LSR recently:<br><a href="https://reviews.llvm.org/rL324289" target="_blank">https://reviews.llvm.org/<wbr>rL324289</a><br>to solve:<br><a href="https://bugs.llvm.org/show_bug.cgi?id=35681" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=35681</a><br></div>...and as noted in the trailing comments, that change needs refinement to account for uarch diffs.<br></div><br>Later, I hit this (still undocumented AFAIK) perf problem related to LSR:<br><div><div><div><a href="https://bugs.llvm.org/show_bug.cgi?id=36180" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=36180</a><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 9, 2018 at 5:45 PM, via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> From: <a href="mailto:fglaser@apple.com">fglaser@apple.com</a> <<a href="mailto:fglaser@apple.com">fglaser@apple.com</a>> On Behalf Of <a href="mailto:escha@apple.com">escha@apple.com</a><br>
> Sent: Saturday, April 7, 2018 8:22 AM<br>
<span class="">><br>
>> I realize this is a micro-op saving a single cycle.  But this reduces the instruction count, one less<br>
>> instr to decode in a potentially hot path. If this all makes sense, and seems like a reasonable addition<br>
>> to llvm, would it make sense to implement this as a supplemental LSR formula, or as a separate pass?<br>
><br>
> This seems reasonable to me so long as rbx has no other uses that would complicate the problem; I’m not sure how much this occurs in hot code (a loop with an induction variable<br>
> that isn’t used in the loop), but if it does, I don’t see why not.<br>
<br>
</span>Thanks for this response and the examples!  I too think it could be a win, and I've explored both: implementing this as a pass (machine function pass) and as a SCEV expression for LSR (an LSR formula).  I'm still on the fence about which approach is the 'best', or more widely accepted.  To me it seems to be more advantageous to add this as an LSR formula, that pass provides a cost model and is target independent.  However, it does rely on the fact that X86 sets the zero flag for inc/add, I'm not sure about other architectures.  Additionally, this change would be fairly similar to what LSR already does.<br>
<div class="HOEnZb"><div class="h5"><br>
-Matt<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>