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

[Daniel Berlin via llvm-dev]

On Mon, Feb 27, 2017 at 12:06 PM, Adam Nemet <anemet at apple.com> wrote:

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

I think the part i missed is now I assume you are also talking about
removing loads and stores *in the duplicated loop*, and not the original.

IE you aren't just adding aliasing checks, and having it be able to remove
loads/stores in the non-alias-checked branch, right?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170227/269372cc/attachment-0001.html>