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

> On Feb 27, 2017, at 10:11 AM, Hal Finkel <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.

Adam
> 
>  -Hal
> 
>> 
>> I guess the pipeline to experiment with for now is opt -loop-vectorize
-loop-vectorize -newgvn.
>> 
>> Adam
>> 
>>> The only thing you'd have to do is write some code to set
"live on entry" subgraph variables in their own congruence classes.
>>> We already do this for incoming arguments.
>>> 
>>> Otherwise, it's trivial to make it only walk things in the
subgraph.
>>> 
>>> 
>> 
> 
> -- 
> 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/4292bc10/attachment.html>

On Mon, Feb 27, 2017 at 11:29 AM, Adam Nemet <anemet at apple.com> wrote:
>
> On Feb 27, 2017, at 10:11 AM, Hal Finkel <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>
wrote:
>
>
>
> On Mon, Feb 27, 2017 at 9:29 AM, Adam Nemet <anemet at apple.com>
wrote:
>
>>
>> On Feb 27, 2017, at 7:27 AM, Hal Finkel <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'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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/e3343687/attachment.html>

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>