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

Tue Feb 28 05:09:44 PST 2017

I have tried running both gvn and newgvn but it did not helped in hoisting the alias checks:

Please check, maybe I have missed something.

<TestCase>
void foo (char *A, char *B, char *C, int len) {
  int i = 0;
  for (i=0 ; i< len; i++)
    A[i] = B[i] + C[i];
}

<Command>
  $ opt –O3 –gvn test.ll –o test.opt.ll
  $ opt –O3 –newgvn test.ll –o test.opt.ll

“test.ll” is attached, it got already vectorized by the approach running vectorizer twice by annotate the remainder loop with metadata to limit the vectorization factor for epilog vector loop.

Regards,
Ashutosh

From: anemet at apple.com [mailto:anemet at apple.com]
Sent: Tuesday, February 28, 2017 1:33 AM
To: Hal Finkel <hfinkel at anl.gov>
Cc: Daniel Berlin <dberlin at dberlin.org>; Nema, Ashutosh <Ashutosh.Nema at amd.com>; Zaks, Ayal <ayal.zaks at intel.com>; Renato Golin <renato.golin at linaro.org>; mkuper at google.com; Mehdi Amini <mehdi.amini at apple.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [Proposal][RFC] Epilog loop vectorization

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

Yeah, that is the problem but I think Danny misunderstood what I was trying to say.

This was a datapoint to possibly rerun GVN with memory-awareness.

 -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/20170228/88123c95/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.ll
Type: application/octet-stream
Size: 9897 bytes
Desc: test.ll
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170228/88123c95/attachment.obj>