[llvm-dev] [Proposal][RFC] Epilog loop vectorization

[Hal Finkel via llvm-dev]

On 02/27/2017 01:47 PM, Daniel Berlin wrote:
>
>
> On Mon, Feb 27, 2017 at 11:29 AM, Adam Nemet <anemet at apple.com 
> <mailto:anemet at apple.com>> wrote:
>
>
>>     On Feb 27, 2017, at 10:11 AM, Hal Finkel <hfinkel at anl.gov
>>     <mailto:hfinkel at anl.gov>> wrote:
>>
>>
>>     On 02/27/2017 11:47 AM, Adam Nemet wrote:
>>>
>>>>     On Feb 27, 2017, at 9:39 AM, Daniel Berlin <dberlin at dberlin.org
>>>>     <mailto:dberlin at dberlin.org>> wrote:
>>>>
>>>>
>>>>
>>>>     On Mon, Feb 27, 2017 at 9:29 AM, Adam Nemet <anemet at apple.com
>>>>     <mailto:anemet at apple.com>> wrote:
>>>>
>>>>
>>>>>         On Feb 27, 2017, at 7:27 AM, Hal Finkel <hfinkel at anl.gov
>>>>>         <mailto:hfinkel at anl.gov>> wrote:
>>>>>
>>>>>
>>>>>         On 02/27/2017 06:29 AM, Nema, Ashutosh wrote:
>>>>>>         Thanks for looking into this.
>>>>>>         1) Issues with re running vectorizer:
>>>>>>         Vectorizer might generate redundant alias checks while
>>>>>>         vectorizing epilog loop.
>>>>>>         Redundant alias checks are expensive, we like to reuse
>>>>>>         the results of already computed alias checks.
>>>>>>         With metadata we can limit the width of epilog loop, but
>>>>>>         not sure about reusing alias check result.
>>>>>>         Any thoughts on rerunning vectorizer with reusing the
>>>>>>         alias check result ?
>>>>>
>>>>>         One way of looking at this is: Reusing the alias-check
>>>>>         result is really just a conditional propagation problem;
>>>>>         if we don't already have an optimization that can combine
>>>>>         these after the fact, then we should.
>>>>
>>>>         +Danny
>>>>
>>>>         Isn’t Extended SSA supposed to help with this?
>>>>
>>>>
>>>>     Yes, it will solve this with no issue already.  GVN probably
>>>>     does already too.
>>>>
>>>>     even if if you have
>>>>
>>>>     if (a == b)
>>>>     if (a == c)
>>>>      if (a == d)
>>>>      if (a == e)
>>>>      if (a == g)
>>>>
>>>>
>>>>     and  we can prove a ... g equivalent, newgvn will eliminate
>>>>     them all and set all the branches true.
>>>>
>>>>     If you need a simpler clean up pass, we could run it on sub-graphs.
>>>
>>>     Yes we probably don’t want to run a full GVN after the
>>>     “loop-scheduling” passes.
>>
>>     FWIW, we could, just without the memory-dependence analysis
>>     enabled (i.e. set the NoLoads constructor parameter to true). GVN
>>     is pretty fast in that mode.
>
>     OK.  Another data point is that I’ve seen cases in the past where
>     the alias checks required for the loop passes could enable GVN to
>     remove redundant loads/stores.  Currently we can only pick these
>     up with LTO when GVN is rerun.
>
>
> This is just GVN brokenness, newgvn should not have this problem.
> If it does, i'd love to see it.

I thought that the problem is that we just don't run GVN after that 
point in the pipeline.

  -Hal

>
> (I'm working on the last few parts of turning it on by default, but it 
> requires a new getModRefInfo interface to be able to get the last few 
> testcases)
>

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/07d7de24/attachment.html>