[llvm-dev] Removing the LoopInstSimplify pass

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] Removing the LoopInstSimplify pass

韩玉 via llvm-dev
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.


vedant

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Removing the LoopInstSimplify pass

韩玉 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.


vedant


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Removing the LoopInstSimplify pass

韩玉 via llvm-dev
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 <[hidden email]> 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.


vedant


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Removing the LoopInstSimplify pass

韩玉 via llvm-dev

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 <[hidden email]> 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.


vedant


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev




_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] Removing the LoopInstSimplify pass

韩玉 via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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.


vedant


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev