[LLVMbugs] [Bug 4393] New: Default AA used instead of supplied AA

bugzilla-daemon at cs.uiuc.edu bugzilla-daemon at cs.uiuc.edu
Sun Jun 14 10:14:35 PDT 2009


           Summary: Default AA used instead of supplied AA
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu

If a pass doesn't preserve AA (such as -simplify-cfg), then the passmanager
will remove the custom AA supplied on the commandline from AvailableAnalysis,
and thus the next time another pass needs AA (for example -gvn) it will
find the immutable basic AA as implementation.
The workaround is to manually rerun the custom AA after a pass that doesn't
preserve AA. This shouldn't be necessarry, the passmanager should remember
what the preferred implementation for an interface/analysisgroup is,
and rerun it if it was invalidated.

If I try to implement a custom AA as an immutablepass, then it is impossible to
use it, even if there is no other pass between -custom-aa and -gvn.
The reason is that the custom AA will get basicAA added as dependency (by the
the parent AliasAnalysis::getAnalysisUsage), and thus
ImmutablePasses will contain BasicAA, then my CustomAA
findAnalysis will thus find BasicAA as implementing AliasAnalysis, before my
pass, thus my pass is never chosen as implementing the interface.

The reason is that dependent analysis are added to various lists
(immutablepasses), before the analysis itself.

I think the passmanager shouldn't rely on the order analysis are added to
immutablepasses (since there is no way to add your own AA as first),
but instead use another Map that specifies the preferred implementation.

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list