[PATCH] D38569: Expose must/may alias info in MemorySSA.

Daniel Berlin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 6 07:56:16 PDT 2017


dberlin added inline comments.


================
Comment at: lib/Analysis/MemorySSA.cpp:269
   if (UseCS) {
     ModRefInfo I = AA.getModRefInfo(DefInst, UseCS);
     return I != MRI_NoModRef;
----------------
asbirlea wrote:
> dberlin wrote:
> > It is possible for a call to must-alias a single thing, no?
> > 
> That's true. I didn't add that because I didn't see how we would use the must info here.
> 
> If we know the call does not modify and it's a must alias, then we could consider some transformation (read: promotion). In practice, we won't promote calls, so keeping FoundMustAlias = false (i.e. may) should be conservative.
> The right thing is reseting to may for calls: 
> if(I != MRI_NoModRef) FoundMustAlias = false;
> (instead of keeping the given value).
I would do the right thing for calls, IMHO, if we can.
(especially since we have to solve the double alias() call issue for other things anyway).

While LICM may not promote them, PRE definitely does (and GCC tests that it does).

This is true even through function pointers.
Here's the non-aliasing version to give you an idea (the aliasing version is longer)

```
double f(double a)
 {
   double b;
   double c,d;
   double (*fp) (double) __attribute__ ((const));

 double (*fp) (double) __attribute__ ((const));
   /* Partially redundant call */
   if (a < 2.0)
     {
       fp = sin;
       c = fp (a);
     }
   else
     {
       c = 1.0;
       fp = cos;
     }
   d = fp (a);
   return d + c;
 }
```

the fp call will get pushed into the else branch.
In the equivalent loop, we could promote it (PRE could promote it too if you let it speculate)
If we determine it is a must-alias of a single thing, we could do the same.
If we determine it's a must-alias of a set of things, we could do the same 
If we determine it's a must-alias of the live on entry def, etc




https://reviews.llvm.org/D38569





More information about the llvm-commits mailing list