[llvm-dev] valid BasicAA behavior?

Chawla, Pankaj via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 18 16:15:40 PDT 2020


>> DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another method added to AA that gives additional guarantees. Please see the bug report for details.

Thanks for updating the bug report but GetUnderlyingObject() doesn't help in this case. The underlying object of the phi is phi itself. I don't think any amount of change on the client side will help because AA interface doesn't give the guarantee DI needs.

>> As far as the AA interface specification is concerned, the NoAlias result is correct. Such a patch would be a pessimization without giving any additional guarantees.

Ok, fair point. 
So the only option left is to introduce a new AA interface which does provide the guarantees needed by DI, correct?

-Pankaj

-----Original Message-----
From: Michael Kruse <llvmdev at meinersbur.de> 
Sent: Wednesday, March 18, 2020 2:43 PM
To: Chawla, Pankaj <pankaj.chawla at intel.com>
Cc: Michael Kruse <llvmdev at meinersbur.de>; Kruse, Michael <michael.kruse at anl.gov>; Finkel, Hal J. <hfinkel at anl.gov>; Hiroshi Yamauchi <yamauchi at google.com>; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] valid BasicAA behavior?

As far

Am Mi., 18. März 2020 um 11:34 Uhr schrieb Chawla, Pankaj
<pankaj.chawla at intel.com>:
> >> There seems to be a bug in DI, see Felipe's answer.
> Maybe I missed something. There seems to be no resolution to the problem. How can DA fix this without help from alias analysis?

DependenceInfo is not using the AA interface correctly. Either DI has to be fixed, or another method added to AA that gives additional guarantees. Please see the bug report for details.


> >> Since aliasPHI looks for any incoming value contradicting the NoAlias assumption, it would be equivalant to always return MayAlias.
> I pasted the code snippet below with some extra comments.

As far as the AA interface specification is concerned, the NoAlias result is correct. Such a patch would be a pessimization without giving any additional guarantees.


Michael


More information about the llvm-dev mailing list