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

[Adam Nemet via llvm-dev]

> On Feb 27, 2017, at 12:04 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
> 
> 
> 
> On Mon, Feb 27, 2017 at 12:01 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
> 
> 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.
> 
> Then i misunderstand.
> 
> "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."
> 
> Why would GVN suddenly be able to remove redundant loads and stores due to insertion of alias checks?
> 
> It should have been able to remove them regardless.
> 

Ah I think I know what you’re missing.  When adding alias checks we also insert no-alias metadata that GVN interprets.

Adam

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