[llvm-dev] Removing the LoopInstSimplify pass

Thu May 24 17:18:58 PDT 2018

And now I'm planning to re-introduce it. I'll at least add test coverage.
I'm also going to put it into the main loop pass pipeline so I can remove
simplification logic from unswitching (at least for the new PM).

On Mon, Mar 5, 2018 at 1:52 PM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The code is simple enough that I'd vote to delete and reintroduce later if
> needed.  :)
>
> Philip
>
> On 03/05/2018 01:23 PM, Vedant Kumar wrote:
>
> Thanks for sharing this background information :). If you've got the time,
> I think it'd be great to check this bulleted list into docs/. I see that we
> don't have a Canonicalizations.rst or a LoopOptimizations.rst -- your notes
> look like a good starting point.
>
> Given that the pass seems to be doing the right thing from a design
> perspective, should it stay in tree? Since it's been off-by-default since
> it was introduced in 2011, I'm still in favor of removing it unless someone
> is actively working on it.
>
> [+ Chad, one of the pass contributors, for comment.]
>
> thanks,
> vedant
>
>
> On Mar 5, 2018, at 8:47 AM, Philip Reames <listmail at philipreames.com>
> wrote:
>
> We're not actively using this, but from a design perspective I'm wondering
> if we should be using this or something like it.  At the moment, our
> various loop optimization assume mostly canonical input.  Some of the
> passes have been taught to deal with limited amounts of non-canonical-ism,
> but there's a strong code simplicity argument in favor of only handling
> canonical input and then having something else canonicalize if necessary.
> Given our loop passes are iterated to a fixed point, having that
> canonicalization done in another loop pass seems appropriate.  This pass
> seems like a start down that path.
>
> Since we don't really document this anywhere, let me describe what I see
> as a canonical loop:
>
>    - Use LCSSA, and LoopSimplify form.  Meaning no-uses of instructions
>    defined in loop outside of loop and phis of loop exit blocks.  Preheaders
>    available.  Unique (unshared) exit blocks.
>    - All trivial CSE done.  I include both arithmetic and load
>    elimination for constant memory.
>    - All instsimplify style simplifications available within the loop and
>    preheader done.  There's an argument for doing instcombine style
>    optimizations within the loop as well, but that's less clear to me.
>    - All trivial LICM done.  By this I mean LICM which does not require
>    aliasing or speculation safety logic.  This is Loop::makeInvariant.
>    - All trivial branches discharged.  By this I mean both CFGSimplify
>    style elimination of constant branch conditions, but also CVP, KnownBits,
>    and SCEV.  (Today, this is often true on entry to a loop pass manager, but
>    is not upheld as passes run.)
>
> To be clear, the above list is aspirational.  We definitely don't do all
> of the above today.  :)
>
> Philip
>
> On 03/02/2018 04:36 PM, Vedant Kumar via llvm-dev wrote:
>
> Hi,
>
> I think we should remove the LoopInstSimplify pass, as it has no test
> coverage and no users (afaik).
>
> If you are using the pass, or think that it should stay in tree for some
> other reason, please let me know.
>
> Here's the patch: https://reviews.llvm.org/D44053
>
> vedant
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> 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/20180524/b0275fa8/attachment.html>