[PATCH] Loop Versioning for LICM

[Nema, Ashutosh]

Thanks Silviu for looking into this.

At this moment we are only considering loops whose trip count is computable.
Scenario you suggested looks valid, and it can be solved by using runtime checks.

If we can prove var2 is not aliased with var1 & var2 then probably we can transform 
the versioned loop like below:

3 (*var2->type()) itr = *var2;
4 for(; j < itr; j++) {
5   var3[j] = 2 * var1[j];
6 }

The suggested test looks very simple but there can be others tricky scenario as well 
i.e. var2 can be used/updated in the loop etc.

I can't assure we will consider this as the part of current change.
I'll give some time to it and if it looks possible then I'll include in this change.

> My guess is that this would require some loop structure that would be similar to what the 
> loop vectorizer is using - which would increase the number of similarities with the loop 
> vectorizer. Would there be any reason not to use the same loop structure the loop vectorizer 
> is using (and share the code that generates it) right now? I think this would actually simplify 
> some parts of the pass and should be the good to do anyway.
Didn’t understood this point completely, which structure you mentioning about ?
We are already using LAA(Loop access analysis) as the part of loop versioning.
It’s used for feasibility checking and memcheck generation.

Thanks, 
Ashutosh

-----Original Message-----
From: silviu.baranga at arm.com [mailto:silviu.baranga at arm.com] 
Sent: Thursday, May 21, 2015 4:25 PM
To: Nema, Ashutosh; listmail at philipreames.com; anemet at apple.com; hfinkel at anl.gov
Cc: silviu.baranga at arm.com; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Loop Versioning for LICM

Thanks for working on this! This has the potential of solving a lot of other problems as well.

I think there would be a problem in cases where some aliasing issue is preventing SCEV from computing the loop trip count? For example:

1 int foo(int * var1, int * var2, int * var3) {
2 unsigned j = 0;
3 
4 for(; j < *var2; j++) {
5   var3[j] = 2 * var1[j];
6 }
7 }
Here var2 can alias with var3[j] so *var2 would not be considered loop invariant, which would cause SCEV to not be able to compute the trip count.

That would be a difficult thing to solve and I'm not saying that this should be part of this work, but it would be good if we could think at least in principle now how we could work around that (I believe it is actually possible to fix the issue using runtime checks) and make sure the design reflects this.

My guess is that this would require some loop structure that would be similar to what the loop vectorizer is using - which would increase the number of similarities with the loop vectorizer. Would there be any reason not to use the same loop structure the loop vectorizer is using (and share the code that generates it) right now? I think this would actually simplify some parts of the pass and should be the good to do anyway.

Cheers,
Silviu


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D9151

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/