[llvm-dev] Removing the LoopInstSimplify pass

[Philip Reames 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 <listmail at philipreames.com 
>> <mailto: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 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/19788cba/attachment.html>