[llvm-dev] SCEV and LoopStrengthReduction Formulae

[Sanjay Patel via llvm-dev]

Changes to x86 LSR can lead to surprising perf outcomes. Test any changes
carefully across multiple uarches.

I added a small bit to LSR recently:
https://reviews.llvm.org/rL324289
to solve:
https://bugs.llvm.org/show_bug.cgi?id=35681
...and as noted in the trailing comments, that change needs refinement to
account for uarch diffs.

Later, I hit this (still undocumented AFAIK) perf problem related to LSR:
https://bugs.llvm.org/show_bug.cgi?id=36180


On Mon, Apr 9, 2018 at 5:45 PM, via llvm-dev <llvm-dev at lists.llvm.org>
wrote:

> > From: fglaser at apple.com <fglaser at apple.com> On Behalf Of escha at apple.com
> > Sent: Saturday, April 7, 2018 8:22 AM
> >
> >> I realize this is a micro-op saving a single cycle.  But this reduces
> the instruction count, one less
> >> instr to decode in a potentially hot path. If this all makes sense, and
> seems like a reasonable addition
> >> to llvm, would it make sense to implement this as a supplemental LSR
> formula, or as a separate pass?
> >
> > 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
> > that isn’t used in the loop), but if it does, I don’t see why not.
>
> 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.
>
> -Matt
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180410/585821b6/attachment-0001.html>