[llvm-dev] Removing the LoopInstSimplify pass

[Philip Reames via llvm-dev]

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 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/20180305/014048ba/attachment.html>